The web has been alive with discussion on web fonts after yesterday’s announcement of the Google Font API. I wrote about it myself yesterday and here is just a quick sample of some of the more interesting articles and discussions:

• Real Fonts and Rendering: The New Elephant in the Room – Jeffery Zeldman, 24 Ways
• Google getting into the Web Fonts game? – Typophile Discussion
• Details on the new Google Webfont API – Paul Irish
• @font-face rendering flow chart – Typophile Discussion

Yesterday I commented on the legibility of the fonts in Google’s Font Directory on Windows with ClearType turned on. After seeing Miha’s awesome  font rendering chart, I can see that my run down of Windows font rendering is only partially correct: Windows XP on default renders in “standard” mode which allows for a limited anti-aliasing smoothing but only at large font sizes or for fonts with proper Windows hinting—unless you are using IE6 and then no anti-aliasing occurs and it’s pixels, pixels, pixels.

As Zeldman points out there are more issues between browsers as well, with each browser handling font hinting a little differently, but that’s a mess I’m not about to get into. What I will do is expand my review of Windows font rendering to cover what it looks link with standard mode and no anti-aliasing. Also for your convince, I’ve added screenshots showing what it looks like with each mode (each font name links to it’s corresponding screenshot):

Windows ClearType

Vista, Windows 7, Windows XP with IE7/8, XP with ClearType turned on

Windows Standard Mode

Windows XP default with Firefox or Chrome

Windows No Anti-Aliasing

Windows XP default with IE6

Again I didn’t bother creating a list for Mac. If you are working on Windows you can use Safari to see what the rendering will look like on a Mac. Macs render type in a more consistent manner: as it decreases in size at worst it becomes a little more anemic and fuzzy. In the main, if your type is legible on Windows it is legible on a Mac.

Conclusion

Now looking at all these Windows rendering styles you can see how varying typeface legibility is:  some fonts behave well across all rendering like Droid and others preform only good with one type of rendering like Inconsolata, which looks good in standard mode but terrible in ClearType and with font smoothing off.

The Droid Family is the only font in this set that I would use for body text. All others are only suitable for headers or display text. And I would avoid using Inconsolata, Tangerine, Josefin, and Cardo except at really large display sizes (36px or larger).

Oh what a happy day to be a Web Developer! Google has released their Google Font API and the Google Font Directory with a number of Open Source Fonts. Also released in cooperation with TypeKit is the WebFont Loader which helps the FOUT (Flash of Unstyled Content) which is an issue with how Firefox handles downloaded fonts ( for more on FOUT and why WebLoader is a good thing see Paul Irish’s Details on the New Google WebFont API).

All this is great as it make it a snap to use open source fonts, either the one’s Google hosts (fast download! easy!) or you use WebFont Loader to make it simple to add other Open Source Fonts such as some of the great ones offered by The League of Movable Type. If there are licensed fonts you want to use, I recommend looking into TypeKit‘s services.

CrossPlatform Rendering Issues in a NutShell

So now that the issue of web fonts is more or less solved, the next big issue is cross-platform font rendering. The best way to sum up the difference :

Mac: the goal of font rendering is to preserve the design of the typeface as much as possible, even at the cost of a little bit of blurriness.

Windows ClearType (Vista,Windows 7, anyone using IE7/8, and XP users smart enough to turn on ClearType): the shape of each letter should be hammered into pixel boundaries to prevent blur and improve readability, even at the cost of not being true to the typeface. It is up to the font designers to build ClearType hinting into the font—without it the font may become illegible at small sizes.

Windows no anti-aliasing (XP default): pixels, pixels, pixels.

much of the above was paraphrased from a great post by Paul Irish: Font Rendering: Respecting The Pixel Grid

In practice this means that Windows users tend to think type on a Mac looks blurry and Mac users think that type on Windows looks jagged and crappy. Also, and more important is that a font needs to be hinted for Windows ClearType renderer or else at sizes under 20px it becomes ugly and often illegible at smaller sizes.

For a more detailed breakdown of how fonts are rendered check out this awesome font rendering chart by Miha.

What does this mean for the typefaces in the Google Font Directory?

So if you are a Mac user without a Windows box around you’ll mostly want to know which fonts are ugly/illegible at small sizes. I’ve taken a brief look at the fonts Google offers on my Windows PC here at work and came up with the following list. Note that some of these typefaces are meant as display only so they shouldn’t be used small anyway:

UPDATE: for a more complete chart with screenshots including Windows Standard Mode and no anti-aliasing check out Comparing Open Source Fonts – Part 2

Open Source Fonts Appearance With Windows ClearType

Open Source Fonts Appearance With a Mac

You’ll notice that I haven’t compiled a table like I did for Windows. That’s because Mac font rendering stays true to the font; thus, you can assume that display type fonts look bad at small sizes and fonts made for body text are good down to at least 12px. Also if you are on a Windows box you can easily see what it looks like on a Mac:  Download Safari and turn on it’s font smoothing (Preferences > Appearance > Font Smoothing > Light or Medium) which makes the font rendering behave (mostly) like a Mac.

*Inconsolata is a good example of a font not hinted for ClearType which looks ugly on Windows below 24px and becomes illegible at 14px; however, on a Mac it looks good even at 11px.