On type & fonts

Type design notes      Font production notes      Type & font tweets

The different faces of type

3 August 2009

@font-face will soon make it possible to use any typeface for web site design, rather than relying on a few 'web-safe' standard fonts which are installed on almost every computer. Discourse currently is centered around the ideal web font format.[1] But there is another aspect which @font-face will inevitably draw attention to: One and the same typeface looks very differently on different platforms, and even on the same platform if settings differ.
There are a few screenshots below, made in Windows as well as Mac OSX web browsers, of CFF-OTF as well as TTF fonts, hinted as well as unhinted. Unlike in other @font-face 'showcases', it is not intended to demonstrate how good type can look at larger sizes, but rather to point out how bad type can look at reading sizes and smaller.


These screenshots are not color-corrected, nor have profiles been preserved. OSX screenshots look a bit darker if viewed in Windows, and Windows screenshots look a bit lighter if viewed in OSX. Also, color fringing as of ClearType and OSX rasterization may appear more extreme than on the source computer. So while it is recommended to not take these screenshots at face value, they represent general tendencies.[2]

CFF-OTF in Windows

CFF-OTF fonts as they look in Windows. From left to right: hinted CFF-OTF, unhinted CFF-OTF, and for comparison, unhinted CFF-OTF in OSX.
Hinted: The pixel-grid fitting destroys the rhythm. In the center line, there is no distance between 'ag', a one-pixel distance between 'au' and a two-pixel distance between 'um'. This effect is not related to font quality, it will show even with fonts from Adobe as can be seen in the Arno Pro and Minion Pro examples below. Unhinted: Without hinting information, type is greyscaled and looks much too dark – even if compared to the relatively dark OSX rasterization.
We have seen here how differently the CFF-OTF rasterizer treats hinted and unhinted fonts in Windows. In the next section, we will see that in OSX, format or presence of hinting do not make a difference.

CFF-OTF and TTF in Mac OSX

Different formats as they look in OSX. From left to right: unhinted TTF, unhinted CFF-OTF, hinted CFF-OTF.
Regardless of format or hinting, typefaces look not perfect but equally good.
Two remarks: To a Windows user who is trained to see pixel-font-like 'crisp' type, this will look 'blurry'. (When I exchanged my PC for a Mac years ago, this was also my impression of OSX rasterization, but after a short period I got accustomed to it and today do not want to miss it any more.) Also, these small ppem-sizes are too small to be considered reading sizes, they represent extreme cases.

CFF-OTF (hinted) in Windows and OSX

A hinted CFF-OTF. Left and right: Windows and OSX.
Windows: Type is rasterized too light – one effect of hinting is that despite increasing size, stems remain about one pixel wide so that effectively type gets thinner as size increases. Some elements are so light that they seem to break away. And thanks to pixel-grid fitting, the text rhythm gets lost. Compare 'THIS' at various sizes.[3] OSX: Type looks a bit dark but it is readable down to small sizes. It is even possible to recognize the typeface's original design.
This was Adobe Arno Pro. Below is Adobe Minion Pro. The result is a bit better because the design itself is more regular, yet the essential issues are the same.[4]

TTF (unhinted) in Windows

Unhinted TTF fonts get a clear No! from Windows. From left to right: with Standard greyscaling, with ClearType rasterization, and for comparison, with Mac-style rasterization.
Standard greyscaling: At text sizes this is a washed-out grey.[5] ClearType: There is more contrast but lines, especially horizontals, seem to break away. Mac-style rasterization in comparison produces a solid text image.

TTF (hinted) in Windows

For hinted TTF fonts we chose two examples from Microsoft's ClearType Collection. Here, rasterizer and fonts jointly cooperate to give optimal results (the middle column). The first example is Corbel. From left to right: Standard greyscaling, ClearType, and for comparison, Mac-style rasterization.
The second example is Constantia. Again, from left to right: Standard greyscaling, ClearType, and for comparison, Mac-style rasterization.


To be clear about this: These screenshots are not meant to point at individual typeface. To the contrary. Choosing Adobe's Arno Pro and Minion Pro and two of Microsoft's ClearType Collection flagships should make it evident that – this is my position – the problem is rasterizers rather than fonts:
In Mac OSX, type is rendered quite bold. I regard this as a minor issue and hope that it will be addressed. Type is readable and the original design is still visible.
In Windows, there is a diversity of rasterizers at work, and results depend much on font format, level of hinting, and the user's choice of a rasterizer. CFF-OTF fonts look bad at text sizes regardless if they are hinted or not: If unhinted, then type is greyscaled much too dark.[4] If hinted, then the pixel-grid fitting destroys the text rhythm, and type gets thinner with increasing size. Turning to TTF fonts: If unhinted, then type looks too grey with Standard greyscaling, and with ClearType rasterization shows more contrast but some elements break away. If hinted, then type looks 'clear' with ClearType rasterization,[2] and with Standard greyscaling the results are far less optimal.
For acceptable ClearType rasterization, fonts must be hinted. Currently, a handful of fonts take advantage of this rasterizer. I am not sure if the extra hinting work really pays. This is more evident when comparing ClearType results with OSX rasterization which, though not ideal, represents type faithfully and in a readable way. No extra hinting work is required. Scrolling up and down this page and focussing on the right column may illustrate what I mean.
Worse, the equation Windows = ClearType is an imaginary one. The ClearType advantage is lost as soon as a user chooses Standard greyscaling. 'Font smoothing', after all, is an option in Windows (including in Windows 7 where it is active by default but still is an option) so that a type designer cannot predict whether users would activate ClearType rasterization or Standard greyscaling – and effectively needs to prepare fonts for both of these options.
Previous discussions were distorted: On the Mac side, OSX rasterization cares for all fonts out there. As a consequence, any font picked as an example is indeed representative of OSX rasterization. On the Windows side, examples were heavily hinted system fonts and more recently are ClearType fonts in the rasterizer for which they have been produced. All other fonts are either kept out of the discussion or declared to be of low quality. But how representative are a few selected fonts manufactured to take advantage of particular rasterization methods? Not to mention that these rasterization methods are not necessarily activated on end users' machines – so that the conditions required to produce these showcase examples cannot be expected to be met in the real world.
So far, hinting was considered part and parcel of digital type. From now on, I suggest, consider unhinted fonts as the norm and make sure that rasterizers get the most out of them, and additional hinting as bonus. (Perhaps a font is considered as hinted only if the 'gasp' table indicates ClearType rasterization, to rule out badly auto-hinted TTF fonts?)
Future higher-resolution displays like the one announced by PixelQi may do type a favor. But this, admittedly, is my optimistic long-term perspective.
The web font format question will be decided by a comittee rather than an inidividual. But individual type designers soon will need to ask themselves: which are the requirements for a typeface to serve as a good web font? do all my typefaces make suitable web fonts? which font format to choose? And operating system and/or browser developers will need to ask themselves: which kind of fonts are out there? does the majority of them meet my rasterizer's expectations and render nicely? or does my rasterizer need to improve to display all these fonts well, as diverse as they are?
This note addresses only one side of the coin – rasterization. The other side is text layout on different platforms and in different browsers.

Further reading

Jon Tan's Display Type & the Raster Wars.
Jon Tan's Complex Type: CSS Fix, ClearType Miss.
Scott Gilbertson's Boing Boing's Redesign Uncovers the Dark Side of Web Fonts.
Thomas Phinney's Boing Boing Redesign Uncovers Web Font Ignorance which responds to the previous article.
David Berlow's comment about said article.
I do not agree with Thomas Phinney's conclusion. It may be worth citing from Dr Peter Karow's EP/RIDT'98 article Two Decades of Typographic Research at URW: A Retrospective (page 271 in the proceedings):
Working at Adobe in 1995, I learned that hints were the major invention with respect to digital typefaces and that they belong to them due to the typefaces' digital nature. Therefore, in general, (gray)scaling without using hints would be a sacrilege despite the comparisons and tests made by their font people which showed that the best results were obtained without hints.
Given the fact that it was Karow/URW who invented hinting – and according to the article it was Karow himself who made Adobe aware that hinting might help so they invented it again – this statement does have considerable weight.
What is to be discussed is rasterization. Hinting is but one approach, among others, to address the specific problem of rasterization at small ppem sizes. Discussing details like whether or not ClearType should ignore this or that kind of instruction or how to tune ClearType is nice. But this should not distract from discussing the more fundamental questions: Is hinting the only solution available as we are told? And if not, what are the different solutions' advantages and disadvantages?
Hinting of web fonts has been discussed on Typophile a few times now, e.g. in context of Typekit and of individual typefaces, like here and here.
John Daggett's Better Postscript CFF Font Rendering with DirectWrite, about Mozilla testing DirectWrite[2] for rasterizing fonts in the Windows 7 version of Firefox.
Jonathan Kew's & John Daggett's After Firefox 3.6 · New Font Control Features for Designers, by the way, indicates that Mozilla also intends to address the other side: text layout.
Thomas Phinney's Font Rendering in Web Browsers · A Find-Your-Font Adventure gives a visual overview of various rendering results.
More web font related links on Twitter, see especially those to Paul Irish's and Jon Tan's articles.

[1] As a brief overview: Internet Explorer only supports EOT fonts. Firefox supports WOFF fonts since October 2009 and, like Safari and Opera, 'raw' TrueType and OpenType fonts. Chromium/Chrome may support WOFF in future. And type foundries are more than sceptical about licensing 'raw' fonts for online use and prefer delivering font data in a wrapped and possibly compressed format. In 2009, three of these formats were in debate, Microsoft's EOT, albeit in a stripped-down version, Letterror's and TypeSupply's .webfont which is more contemporary and extensible, and Mozilla's ZOT which may be called compressed OpenType. Since end of 2009, ZOT's file structure has been combined with .webfont's metadata, was called WebOTF first and then been renamed to WOFF. In April 2010, Microsoft, Mozilla and Opera have jointly submitted WOFF to W3C.
[2] The ClearType screenshots have been updated. Previously they were too light due a too high gamma value – let me emphasize that this was the default setting on my relatively new computer.
With help of the ClearType Tuner, contrast has been increased. Here a sample with different values:
The earlier ClearType screenshots tended toward the left sample, while the present ones tend to the right one, with a value of 1.2 for the updated ClearType screenshots.
However, this indicates three things: The default setting may be less than optimal. Windows does not encourage users to optimize these setting. To the contrary, it requires an active user who knows about and downloads the ClearType Tuner so he can optimize the settings. Can this be expected from average users like you and me?
Having installed Windows 7 on another computer now, it seems that the gamma value there is pretty high too. So I wonder if my ClearType tuning gave ClearType an unfair advantage – especially since OSX rasterization is shown at default settings.
One more remark. ClearType as of WPF and DirectWrite has been improved. Thin lines won't break away any more. Left and right: An unhinted TTF font with the old ClearType (GDI) and the new ClearType (WPF/DirectWrite).
But this does not help older and current applications that still rely on GDI. Internet Explorer 8 in Windows 7 is a chameleon: It rasterizes HTML pages with the old ClearType (thin lines still break away) and, serving as a host for WPF, rasterizes XAML 'pages' with the new ClearType – in the above image, the right column was prepared with a modified SimpleFontChooser.xaml running in IE8.
For sizes larger than the ones shown above, by the way, rasterization gets funky with heavy horizontals ...
[3] The gap between 'Ta' however is not due to pixel-grid fitting but to the fact that the older rasterizer does not recognize Arno Pro's kerning since the kern feature makes use of an extension-type lookup. So this does not count.
[4] CFF-OTF fonts look better in Windows 7 if rasterized with DirectWrite. What I do not know yet is if applications, and which, already rely on DirectWrite.
[5] The 'gasp' table in this font is set to allow for non-gritfit greyscaling even at small ppem-sizes.

All texts & images, unless noted otherwise:
Copyright © Karsten Luecke
All rights reserved.
All product and company names mentioned may be trademarks or registered trademarks of their respective companies.