Thomas “my other car is a sans serif” Phinney on fonts, typography & text. Geeky troubleshooting and info for font developers and users. Consulting & expert witness for fonts & typography.« Boing Boing Redesign Uncovers Web Font Ignorance
18
- People keep on sending me links to this article “Boing Boing’s Redesign Uncovers Dark Side of Web Fonts,” about problems Boing Boing had with their new web font implementation. Only thing is, the article has a substantial dose of nonsense mixed in with the perfectly good analysis. I don’t blame the writer, though. This web font stuff is actually really complicated, and information has been hard to come by. Heck, I even briefly forgot a basic point in a first pass at this article. But nonetheless, I am fairly sure that Boing Boing could have fixed their problems easily, if they knew how. Here’s the story:
WHAT HAPPENED
The background here is that there are new ways of using fonts with web sites, and Boing Boing tried the simplest approach of just hosting a free font on their own web server and pointing at it, but the on-screen results were not as good as expected.
“…the font it settled on — specifically BPreplay — ended up looking terrible for most users.”
“The result was hordes of angry Boing Boing fans complaining that the new headline font was “ugly,” “an abomination” and “plain nasty.” Of course, the culprit wasn’t really the font, but rather how different it looked depending on which browser and operating system the viewer was using.”
FINDING THE CULPRIT?
This is where things get tricky. I will update this post as I learn more. But, as best as I can tell, if that link to the font is right, and the font wasn’t modified by Boing Boing, the culprit really was in large part the font. But first let’s follow the trail of the previous article and make some corrections….
“The problem is that while modern browsers, like the latest versions of Safari, Firefox, Opera and Google Chrome, all support @font-face, the Windows XP operating system often doesn’t have anti-aliasing turned on by default.”
Not true. Anti-aliasing is on by default in XP. What isn’t usually on by default in XP is ClearType, Microsoft’s enhanced anti-aliasing for LCD screens. Sometimes a computer vendor will turn ClearType on for the computers they sell (particularly if they are laptops or come with an LCD monitor).
But what makes this even less meaningful is that (again assuming the linked font is the right one), the font in question is in OpenType CFF format. Such fonts are always anti-aliased in XP, even if you turn off anti-aliasing—the setting change only affects TrueType fonts. Even ClearType doesn’t affect how these fonts are rendered (rasterized) in web browsers, either. Same thing in Vista, and as far as I know in Windows 7 as well.
“The rule, which is still part of CSS3’s draft specification, is also not supported by any version of Internet Explorer. So, as cool as your font might look when properly anti-aliased, on Windows XP it looks, as Rob Beschizza, head of Boing Boing’s redesign puts it, ‘like ass.’”
I’m not sure how those two sentences are related. That’s a mystery to me. XP can get good anti-aliasing as well as Vista, and Internet Explorer is bundled with Vista and Windows 7 as much as with XP. But even taking those points separately….
The @font-face rule was actually in CSS 2 way back when, and removed in CSS 2.1. Internet Explorer has supported @font-face in every version from IE 4 to the current IE 8, but the catch is they support it only with Microsoft’s “.eot” font format (a wrapper around a TrueType font), not with regular desktop fonts. But there’s a good reason for not supporting regular desktop fonts directly: font vendors mostly won’t license their fonts to be stuck “naked” on web servers without any additional protections. Sure, there are free fonts, but, well, we’ll talk about those in a few minutes.
If Boing Boing simply put up the naked .otf font file, and didn’t do anything for Internet Explorer users (and people running older versions of other browsers), then what font actually got displayed to those users would depend on what Boing Boing specified as the fallback fonts and whether the people actually had those fonts (and thanks to Ben Kiel for reminding me of this in passing). Now, if the fallback stack relied on fonts that most XP users would not have, but Vista users would, then there might be a difference that was at least partly based on operating system. But of course it would simply be up to the folks constructing the CSS for the web site to pick reasonable fallback fonts, and not really the fault of the operating system. Perhaps as a first-level fallback from their desired font they specified one of the so-called “ClearType fonts” such as Calibri or Corbel, which are bundled with Windows Vista and Office 2007. Not quite right to blame XP for not having the font, but that would explain how somebody could mislabel it as an XP-specific problem.
Other than that, whether you are using Windows XP or not has little to do with whether or not the font looks “like ass.” Turning on ClearType can further improve rendering for fonts with TrueType outlines, but would have no effect on this particular font. Being on Vista instead of XP would make no difference at all for any web browser rendering OpenType CFF fonts such as this one.
Side note: The font wouldn’t even be seen in Internet Explorer, because Boing Boing didn’t use its .eot format as far as I know. Any further problems in IE would then be due to a poorly-specified font fallback stack in the CSS. However, if they had used .eot and TrueType outlines…. Although XP has ClearType off by default, newer versions of Internet Explorer turn it on just for the browser, so there isn’t much difference between IE rendering of TrueType fonts between XP and Vista.
In researching what went wrong, it doesn’t help that Boing Boing backed off from the font change part of their redesign, so we can’t look at it and test it. Looking at this screenshot, however, shows pretty clearly what was going on. This screen capture was definitely taken on Windows, and the font in question is still anti-aliased. However, it has some pretty crappy artifacts in how it’s rendered on screen, at least some of which are related to it being unhinted. When I see things like a single pixel sticking out of the bottom of a round shaped letter, that’s a dead give-away that the problem is likely hinting (or more accurately, lack thereof).
“Hinting” is essentially extra code in the font that improves its rendering at screen resolution. Apple’s rendering approach largely ignores hinting, but Microsoft’s rendering still uses it a fair bit. Passable hinting can be done automatically by font editing tools, so there’s no real excuse for leaving it out of a font (as with this one). In fact, pretty much every commercial font on the planet is hinted, as are most free fonts. But this isn’t even an average free font. Yes, the terrible spacing is pretty typical for free fonts, but being unhinted is uncommon. Maybe it was converted by somebody else.
Bottom line: the font sucks. This should not be a surprise. Most free fonts do. Don’t get me wrong. There are a few great free fonts out there. But 98% of free fonts suck badly, and maybe about 20% of typically-priced retail fonts suck badly, so set your expectations appropriately.
THE “DIRTY LITTLE SECRET”
But there’s another problem that might have led to complaints and concerns even if the font was made decently, but still in the same format. The “dirty little secret” of the font world is this: Windows GDI rendering of OpenType CFF and “PostScript” Type 1 fonts on screen just sucks, compared to its rendering of TrueType fonts.
Typophiles have long ignored this fact, because in the environments they’ve cared about, Type 1 and OpenType CFF fonts render perfectly well on screen:
- Just about any application on the Mac OS.
- Adobe Acrobat, InDesign and Illustrator, on any platform.
Unfortunately, Windows GDI rendering is what 90% of people see in web browsers and office applications today. (Yes, Safari for Windows also has the option to use its own rendering system, but that’s a tiny minority.) Internet Explorer sidesteps the problem simply by not supporting OpenType CFF fonts in .eot format, only TrueType (though one can convert). But it’s not like .eot ever caught on with web designers, anyway.
The future could improve. There is much better OpenType CFF rendering, even applying ClearType, available for applications using Windows Presentation Foundation and DirectWrite, but very few applications use these modes today, so it is sadly not very relevant… yet. My recollection is that the technical preview of Office 2010 for Windows has dramatically better rendering of OpenType CFF, so perhaps it is coming. Maybe Internet Explorer 9 will get there too, supporting both outline formats in .eot or some new web font format. Perhaps in five years decent support for OpenType CFF rasterization on screen will have reached the strong majority of web browsers….
CONCLUSION
So for me it’s a toss-up as to whether I blame Windows GDI rendering, or the fact that Boing Boing used a crappy free font (BPreplay) because they couldn’t legally use the retail font they wanted to (VAG Rounded). My first take is that I think Windows GDI just made worse something that would have been a problem anyway. Somebody who knows what they’re doing could spend ten minutes and either fix the font’s hinting in BPreplay or convert it to the TrueType flavor of OpenType—if the license permits it, I’d be happy to try either for them. But then again, maybe the complaint is more about the fallback font, a factor easily controlled by the web site author.
So yes there are some pitfalls. Obviously things would be better if one format worked across all browsers. But there’s also the question of whether one can use the fonts one wants, which tripped up the Boing Boing folks. What happens with that depends on what font vendors decide to do with the fonts they control the licensing for; many foundries are still trying to figure out how to approach the web fonts conundrum. Will they license fonts for use on web servers directly? Will they do so but specify security requirements that can’t be met by sticking regular desktop fonts on web servers, meaning that we’ll have to wait for new web font formats to be widely adopted, such as WOFF? Will they instead rely on a font serving process that involves something centralized, either run by themselves, or by a third party (such as TypeKit or Kernest)?
How exactly this will play out is still TBD today. What I do know for certain is that within a few years, web fonts will be a reality for the average viewer and the average web site. Many or even most web sites will pick specific fonts that aren’t necessarily already on the viewing computer, and those fonts will get used to display the desired text. Font selection will become part of branding for the web the way it has been in print. We’ll also get an explosion of awful font choices on web sites, particularly small personal ones, much like when the masses first got access to a wide variety of fonts they could print on their home computers. But overall, it will be a Good Thing, and I relish the thought of a more typographically rich web world in a year or three.
[Updated for minor clarifications 2009-10-12, reformatted 2009-10-13, added a bit on font fallback 2009-10-13]
18 commentsto “Boing Boing Redesign Uncovers Web Font Ignorance”
Excellent piece, Thomas. Thank you!
The devil was certainly in these details.
Thank you for writing this, Tom. You’re one of the first people to point out that as liberating as @font-face will be, people really need to have reasonable expectations about how “the fonts” will “work” on screen.
OpenType/CFF fonts on screen are definitely not the better choice most of the time, but there are occasions when ClearType’s lack of y-axis anti-aliasing makes TTFs look conspicuous. I’m thinking especially of fonts at headline sizes; have you looked at your Hypatia headline rendered both ways?
[I have indeed, and I agree. But at headline sizes it’s an annoyance, whereas the failings of the GDI rasterizer for fonts with PostScript outlines (Type 1 and CFF) at text and smaller display sizes are a serious functional issue. Later versions of ClearType do better TrueType rendering in this regard, btw: the WPF and presumably the DirectWrite versions of ClearType add Y-girection anti-aliasing. — T]
I totally agree. And that’s good news about WPF & DirectWrite!
Suck how? In what way? Except for heavily hinted “body fonts” designed for smaller sizes, frankly, I’m not seeing much of a problem for more decorative stuff – menu items, headlines and such among free fonts.
And there are two significant ways in which retail fonts suck – 1) they cost money, and 2) the EULA almost never authorizes fixing what may be wrong with the font.
I could name more, but I’m keeping it short.
Cheers, Rich
[The topic of what makes a good font is complicated, but I discussed it a fair bit in an Adobe blog post, four years ago. In short, spacing is the single area that has the highest chance of being completely atrocious in a free font. But there are easily a score of things frequently done incorrectly… to make a mediocre or lousy typeface only takes one mistake, but to make a good typeface pretty much everything has to be right. In the case of BPreplay, it has lumpy curves, incorrect contrast, no hinting, atrocious spacing and sidebearings, inconsistent heights, poor curve-to-straight transitions, and has incorrectly set blue zones. That’s just what I noticed in five minutes. Except for the lack of hinting, it is not unusual among free fonts in having these sorts and number of issues. If I wanted to really fix it completely, I would be better off building a new typeface from scratch. I’d rather have a font that is in good shape and doesn’t allow modification than one that allows modifications but would take me a week to fix. — T]
“Type 1 and OpenType CFF fonts render perfectly well on screen: * Just about any application on the Mac OS.”
Have they patched Snow Leopard? http://www.macuser.co.uk/news/268417
[Not yet. But that issue is only with Type 1, and the problem doesn’t make Type 1 fonts render poorly… just gives them possibly different line spacing than on Snow Leopard compared to other versions of Mac OS. That wouldn’t matter too much for web pages, but being a problem for Type 1 only (not OpenType CFF) it doesn’t affect web fonts, anyway. — T]
Great article, covers pretty much all the factors necessary to conscientious font-family strings for web. Nice one!
I think being wary of free fonts is a pretty superstitious (and political) way of going about things – but that opinion deserves an airing in its own right.
[Superstition is something lacking basis in fact. If one accepts my statement that 98% of free fonts suck (and you may disagree), it is not superstition but pragmatism to be cautious of them as a category. Political? Sure, it has political implications. But I’ve always been happy to praise those high quality free fonts out there, too. — T]
The way to avoid all the symptoms described is simply (as you said) to test thoroughly across platforms & user agents. Personally, I fail to see how this can be an optional nice-to-have in web design.
There are way too many Mac-based web designers who don’t try their wares on any version of IE before releasing – the biggest evidence for this being variations of T1 Lucida Sans on otherwise perfectly beautiful sites looking utterly illegible to Windows users at anything under 18px.
[No question that we agree on the necessity of testing. But aside from that, web fonts are a brave new frontier for web designers at the moment; significant mistakes are to be expected for a while yet, though one expects them to be caught in testing. — T]
Very helpful article. Thank you. When I read: ‘many foundries are still trying to figure out how to approach the web fonts conundrum. Will they license fonts for use on web servers directly? Will they do so but specify security requirements that can’t be met by sticking regular desktop fonts on web servers’, it occurred to me that this may be something to which Extensis could apply its expertise in managing fonts.
LTM
I think, there is another major problem by using BPreplay. The lack of characters for non-English languages. It has only 207 characters and only Greek users can display a fair number of their characters. Different character sets and different encodings can increase these problems too. Boing Boing does not know when they want (or have) to show these “strange characters”. In my opinion their designers (and/or web technicians) did a very bad job.
This has been going on since at least ’99 when I got burnt trying to deploy cross-browser web fonts using MS’ eot and the bitstream truedoc format that Netscape 4 supported. Font-smoothing was off by default in most Windows of the day, and most fonts didn’t smooth (or anti-alias) below 18pt or so. I.e. they looked like ass on the screen in IE.
Which left you with a small collection of screen-optimized fonts to choose from, or the prospect of making your own – not a trivial task. Guess which fonts were screen optimized? Yes, our old friends Verdana, Arial, Tahoma etc. Back to square one.
We were having the same discussions about licensing 10 years ago. Maybe this time around there’ll be a breakthrough? At least nowadays the 100+KB to download a full character set for a font isn’t a deal-breaker.
[There are certainly new approaches which deal with the licensing issues, including http://www.webink.com, the service I’ve helped develop at Extensis.]
Hey there would you mind letting me know which webhost you’re utilizing? I’ve loaded your blog in 3 completely different browsers and I must say this blog loads a lot faster then most. Can you suggest a good web hosting provider at a fair price? Thank you, I appreciate it!
[I’m self-hosted with a tiny provider based in Seattle: CHCS Internet Development. They have provided me with excellent service for my particular needs. I also keep my pages pretty lean, with few graphics and just a few web fonts. — T]