Type Readability on the Web

[ggreig]

There are a couple of interesting videos on Channel 9. They're the latest interview with Bill Hill, one of the most interesting guys to listen to at Microsoft.

Hill's originally from a publishing and typography background rather than software development, so for a start it's a nice change of perspective. He's a very enthusiastic speaker, and as it happens he's also Scottish - he worked on The Scotsman in the days when it was still a credible newspaper.

What he's talking about is trying to improve typography and page layout on the web in order to improve online readability.

He's not a web expert per se - he's picking up standards-compliant HTML and CSS as he goes along - and if you're a web developer, you may have qualms about some aspects of what he's trying to do. For example, his preference for full-screen viewing goes counter to received wisdom about how web content should be designed, and it's fairly easy to find situations in which his sample pages don't work.

However, you should bear in mind that this is work in progress, and that while he's challenging some web assumptions, he really does know his stuff on readability, so it's worth hearing what he has to say. Look past the bits that immediately give you the grue!

The real substance is that Microsoft are opening up their previously proprietary font-embedding technology for the web, and making it clear they won't support the alternative font-linking solution - for reasons that are perfectly good if you believe that type designers deserve to earn a living. Ascender Corporation are explicitly throwing their weight behind this, and it's likely to be supported by others. Hopefully it will also be possible for the other browsers to implement support for font-embedding now that it's no longer proprietary.

tobyaw will be glad to know he may have been ahead of the curve with the embedded-font typography on the Brighthelm web site.

Comments

[tobyaw]

His website looks a little unhappy in Safari.

I can think of a lot of problems with multi-column designs for online viewing, especially if one bumps up the text size. Too few words per line; too much scrolling up and down.

[ggreig]

I think his argument would be that there's not going to be much demand for bumping up the text size by much; 12 point is a comfortable size because of the dimensions of the human eye. However, you're right about multi-column layouts having potential problems if there is mch resizing.

One of the stated goals they're working on - and clearly aren't there yet - is greater responsiveness to rescaling, to the extent that layouts will work on a big-screen multi-column but still be OK on a hand-held device. Be interesting to see what they do.

[qidane.livejournal.com]

Yesterday I set the minimum font size in by browse to 16 pt as I am finding it increasingly hard to read some sites. My main text editor is now at 22pt by comparison. The layout of most sites almost works. But I have noticed some menus having problems.

[ggreig]

Well, that would almost certainly bust his current sample pages. It is clearly something he needs to work on; still, that does seem to be something that's intended.

Is that "true" 16pt (as in resolution independent, would be the same size if you held a print-out up alongside it), or is it dependent on your display?

[tobyaw]

The interesting developments in web browsers to allow full page scaling, rather than just scaling the text within a fixed layout, will really help. Increasing use of vector-based content will be a benefit; its good to see that most browsers now include decent SVG support.

I’m still not convinced that multi-column layouts are appropriate for text-based content on the web. For advertising and information, sure. But for reading a body of text, I want to scroll in one dimension, not two. And for reading on small screen sizes - the iPhone or the Wii for example - a single column that can be zoomed to the page width is the only sane way to present text. Thankfully most web sites work like that.

I can see good functional design arguments for using multi-column text in many forms of traditional publication, but can see very little reason (than an aesthetic desire to ape the printed page) to use multiple columns for on-screen reading. And there are plenty of reasons to use a single-column layout.

[ggreig]

Yes, if you have to do horizontal scrolling then it's a failure. But the goal is to get to the point where there's adaptive layout, where you can have single column in a small window, and multi-column when there's the space to accommodate/require it.

I'm not sure whether that necessarily clashes with full-page scaling; both are ways of trying to make the best use of the available space in the browser. Full-page scaling is probably, in idealistic terms, the less-good solution, but it's likely be more successful, at least in the short term, because it requires less of the page author. Long term - ten to twenty years - adaptive layout could, possibly, become the norm.

Microsoft's failure to support SVG is very annoying; it will be interesting (and possibly frustrating) to see whether SVG continues to suffocate in the meantime or drives adoption of other browsers. I'm inclined to think the former, because most end-users dont know about it and don't care. I'd rather it were otherwise.

[tobyaw]

I’m not sure that SVG is going to be a significant issue in desktop web-browsing in the near future, but I don’t see it suffocating. Particularly with its widespread support on mobile devices, and recent improvements in support across different browser engines, there is a lot of work going on with SVG. Which I approve of, as I find it a very likeable technology.

Interesting table of feature support at http://www.codedread.com/svg-support.php

[ggreig]

Maybe stifle would have been a better choice than suffocate! :-)

[ggreig]

Forgot to mention the poster-child of adaptive multi-colum layout: the New York Times Reader.

[tobyaw]

…and I hate to say it, but having tried font embedding all those years ago with EOT files, I haven’t used it since, as it was such a pain to set up.

Having said that, I’ve been experimenting in the past weeks with with font embedding in Safari. Its clear that Safari, Firefox and Opera will end up supporting the same standard CSS commands for embedding OpenType and TrueType fonts. It works quite well, and I guess will work in most mobile devices too, as they tend to use browsers based on one of these three.

So it makes me wonder whether this is Microsoft’s last gasp at trying to promote its own technology, when its clear that the world and its browser is moving in a different direction.

[ggreig]

Having had a quick look around, what Safari has implemented is font-linking, not font-embedding, and the font foundries really don't like that, because the font can then be easily pirated.

Of course, that may not be an issue if you stick with free fonts, but it's easy to foresee a lot of people sticking fonts up on web servers willy-nilly without regard to proper licensing.

I imagine there will be quite a lot of pressure from the font industry for browsers to implement Microsoft's technology in preference to font-linking, and really there's no reason for them not to since Microsoft have opened the EOT specification up and are putting it forward as a W3C standard.

An indicator that the foundries are taking this seriously is that suddenly Ascender seem to be actively developing their own support for EOT, though as yet it's pretty limited (see their Font Embedding site).

I have to say I think Microsoft have the moral high ground on this occasion (though perhaps less so in the past, when EOT was still closed).

[tobyaw]

I’m not sure that there is a significant difference, other than terminology, between font linking and font embedding, since they both involve accessing the font file using similar CSS.

I can’t see how the potential benefits of EOT - DRM and subsetting - can work in the general case. If open-source browsers can load an EOT file, then surely the protection that links the file to a site could be side-stepped. For sites that depend on dynamic content, the subsetting feature is inappropriate. And the benefits of EOT only apply to the font’s creator - there is no user benefit to DRM.

So what does the EOT file give you over regular OpenType or TrueType? Other than having to rebuild font files for your sites, possibly any time you change the site content, using a tool that hasn’t been updated in five years and only runs on a PC?

The only reason to use it is licensing requirements from the major font companies. And in effect, a combination of poor technology and restrictive licensing has held back web font embedding. The sooner EOT dies, the better.

We have the prospect of being able to embed fonts within the next year in a decent subset of PC browsers, in all Mac browsers, and in most browsers targeting mobile devices. Free fonts are of increasing quality and are widely available, and maybe one of the major font companies will take a lead and develop a sensible licensing solution for web use.

[tobyaw]

And we shouldn’t forget the third major way of embedding fonts in web pages; sIFR. Despite my objections to its methods, it works across platforms and I would guess is significantly more widely used than any of its alternatives. Although I think its only really appropriate for display text, rather than body text.

[ggreig]

Hmmm, yes, it looks pretty stop-gap.

[ggreig]

The DRM is the significant difference.

You're right that DRM won't stop someone who really wants to steal a font. That's probably true even without opening up the EOT specification.

What it does, though, is make casual theft significantly harder, and that's what the foundries are really concerned about. There's quite a big difference between someone going out of their way to crack a font, and all and sundry being able to right-click and select download (oversimplifying slightly to make the point).

Subsetting needn't be an issue for dynamic sites, as it's optional. There are seven subsetting options in WEFT, the last of which is "No subsetting". Presumably any competing tool for WEFT could implement the same options.

I think I'd say that it's neglected technology, rather than poor, and proprietary "standards" (ahem) that have held back web font embedding. However, now that Microsoft have opened up EOT there's scope for open-source and competing implementations. Maybe even clunky old WEFT will get an upgrade!

I strongly disagree if you're saying that font embedding/licensing technology is restrictive. The whole concept of font embedding, which has been around since the early nineties, was quite forward-looking and liberal then and is still pretty fair now. Perhaps you're thinking of individual fonts that fail to license embedding, rather than the mechanism?

[tobyaw]

The interesting comparison is with PDF files, where fonts are easily and commonly embedded, and it is an accepted part of the design process. I’m not sure about the technical restrictions on a PDF-embedded font.

MS Office also allows fonts to be embedded within documents. I’ve not used this, and wonder how widely it is used. Presumably the embedded fonts are accessible by other applications that can parse .doc or .docx files.

[ggreig]

I don't think it's widely used in Word/PowerPoint etc. because it's not widely known. Also I see it's just not supported in the Mac version of PowerPoint, which is a bit of a shocker.

Given the size of modern disks, and even Internet speeds for e-mail attachments, if I were Microsoft I'd be tempted to turn it on by default, with subsetting enabled, but historically that hasn't been done because of the effect on file sizes.

[tobyaw]

I think I’d go for it being turned on my default, but subsetting would be seriously user-unfriendly for any document that is likely to be edited.

[ggreig]

Failing to subset would be user-unfriendly with a complete Unicode font like Arial Unicode MS. It would add about 22MB to every document!

[tobyaw]

Even with the potential benefit for font foundries in DRM (which hasn’t translated into real benefit as the technology isn’t widely used), I don’t see how DRM will offer any protection if there is free source code available to read the files.

Looking at the W3C EOT submission, the fonts are restricted to a list of domains. but it is entirely up to the user-agent to control this. I wonder what benefit there is to browser ‘foundries’ to implement this restriction, or to implement EOT at all?

[ggreig]

Interesting point. Don't know the answer to that one. I think it would be morally dubious for them not to, but that's quite a different matter from legal liability.

If they can't be done for being accessories - and it's difficult to see how they could, as ultimate responsibility would lie with the page author who uploaded a font illegally - then perhaps there isn't enough of a driver.

[sharikkamur.livejournal.com]

He raises some very good points - paperback books are the size they are not only because they're a comfortable size to fit in the hand but they're also a comfortable size to read in terms of saccadic motion. You don't need to have huge eye movements from the right end of the text to the left upon completing a line, and the entire page is within the central (i.e. 4-5 saccades wide) portion of the vision.

It's why I don't like reading novels on the computer - the screen is too wide. Reading them on the Palm is fine because the screen slightly smaller than a paperback.

I like his concept of a 'reading view', but as qidane pointed out it will have to be tweaked a little for people with non-standard visual requirements. The basic premise of a limited width reading column still remains sound though as the central visual field will remain the same.

[ggreig]

That's what I like about what he's saying - he's bringing his experience of printed page readability to online reading. While some of what he's trying to do frankly doesn't quite work yet (and he admits it himself), it's an interesting vision.

[qidane.livejournal.com]

The sample pages look dreadful!

I have text on top of pictures, white text on a white background, and text on top of other text.

[sharikkamur.livejournal.com]

I found that too with Firefox on my Mac. Clearly the technology still needs some work. :)

[ggreig]

Thanks for the screenshot (in e-mail, in case anyone's looking for it here). I tried to view the pages in Safari on the PC, but it crashed! As it also did when I tried to type something - anything - into the search box...

Some of those issues appear even when using IE7 (the misaligned graphic, text on text at some window sizes), but they're not really the point. The point is to show that a multi-column layout and embedded fonts can improve on-screen readability. Admittedly your impression of that is going to be diluted if other presentation issues intrude, but to a certain extent that's unavoidable - Hill's trying to show where he'd like online reading to be able to go, within the limits of what's available now. Those limitations bite harder in some places than others.