Google rolled out its own web font directory during Google I/O 2010 with a rather elegant and easy-to-use API. I’m expecting lots of people would jump on the bandwagon and start using customized fonts instead of the “web safe” but boring fonts (Helvetica, Arial, Verdana, Georgia, and friends). Before you follow suit, here is a list of things you should consider.
Font Formats and Browser Support
Currently there are 4 usable font formats with varying browser support: TTF/OTF, EOT, WOFF, and SVG.
TTF/OTF (TrueType/OpenType) are the formats used by most operating systems to render fonts on screen. There are some problems of using them for the web, though. The primary issue is that type foundries are not happy, because anyone can download these fonts and steal them since there is no way of enforcing license. Another issue is TTF/OTF fonts are not compressed and thus have a larger file size. Personally I don’t think this is too big a trouble since most web servers can be configured to compress on-the-fly or delivery pre-compressed alternatives. Firefox 3.5+, Safari 3.1+, and Chrome 4+ support these formats.
EOT (Embedded OpenType) is Microsoft’s attempt to address the shortcomings of TTF/OTF for the web. EOT is created from existing TTF/OTF fonts by a tool from Microsoft which respects the “no embedding” requirement in certain fonts. EOT allows subsetting (only include selected characters) and compression to reduce file size. EOT was submitted to W3C as part of CSS3 but got rejected. Currently only Internet Explorer supports this format.
WOFF (Web Open Font Format) adopts a similar approach as EOT, and it was submitted to W3C for standardization by Mozilla, Opera, and Microsoft. Firefox supports this format since version 3.6. Microsoft will support it in Internet Explorer 9. Safari and Chrome will also add support for WOFF soon. It’s very likely that in the future WOFF would become the preferred format of web fonts. Before that, you are stuck with EOT + TTF/OTF combination.
SVG (Scalable Vector Graphics) fonts are supported by all WebKit-based browsers, including Chrome, Safari, and Safari Mobile. However, Safari Mobile supports only SVG fonts, so if you are targeting iPhone/iPad, SVG fonts are your only choice. There is one caveat though: SVG fonts are unhinted. Font hinting is extra information embedded in font files to aid rendering at small sizes to improve legibility. Without custom hinting for a particular font, the font engine has to decide on its own, and usually the result is not pretty. Currently WebKit also has a very serious usability issue with SVG fonts. More on this later.
In summary, here is a list of font formats and browser support:
- Internet Explorer 6, 7, 8: EOT
- Internet Explorer 9: EOT, WOFF
- Firefox 3.5: TTF/OTF
- Firefox 3.6+: TTF/OTF, WOFF
- Chrome 4+ / Safari 3.1+: TTF/OTF, SVG (with WOFF coming soon)
- Safari Mobile: SVG
As a web designer you usually don’t have to worry about all this if you use Google Font API or TypeKit, but if you want to use a font that is not available other than hosting it yourself, go back and read this section again. Typically you will need to generate at least EOT and TTF/OTF to cover the majority of users.
Choose the Right Fonts
Not all fonts are created equal. Some fonts are designed for computer screens with extra hinting information (some even embed bitmapped versions for small sizes), while others for printing contain few if any at all. If you want decent quality on screens, make sure you pick those fonts that are proven good looking at small sizes and test with different operating system and browser combinations.
Text Selection Problem of SVG Fonts
WebKit-based browsers (Safari, Safari Mobile, and Chrome) currently have a big usability problem when dealing with SVG fonts: text selection is broken. You cannot select individual characters, or words, or any custom selection. You can only select the whole row or paragraph of text. Before this is fixed, you should probably think twice before using SVG fonts for body text. Decorative text should be fine though, as it is not intended for selection anyway.
File Size and Bandwidth
Web fonts do not come for free for your visitors. They add up to the total download size of web pages. Depending on your choice of fonts and character range, the file size of web fonts varies. Typically one variant (so regular, bold, italics, bold and italics are counted four variants in total, even if they are of the same font family) of a Latin-based font would consume about 30kb. If you use too many fonts and variants, the download size will increase significantly. Visitors with slower connection (e.g. iPhone over 3G networks) will not be happy.
Centralized web font directories like Google Font Directory and TypeKit can partially solve this problem by caching fonts locally on users’ machines so that when a user visits your site using a particular web font, hopefully she already has that font in her browser’s cache from a previous website she visited. This sounds good in theory but in practice if you use a rare font that no many people use you are out of luck.
There are a lot of moving parts which affect the final look of fonts on screen. For example, Windows uses a different font engine than OS X. The same font looks very different on each platform. (Personally I find the one rendered on OS X looks much better.)
Even on Windows there is a difference because of ClearType (Microsoft’s implementation of subpixel rendering). Some fonts, especially those designed for use with ClearType (like the new C-font family in Windows Vista and 7), look really crappy if ClearType is turned off. To make it more complicated, ClearType can be tuned to different levels, resulting slightly different overall appearance of text.
On OS X this is not a big issue since subpixel rendering is on by default (although tuning is possible, few users know how to do that via command line in OS X 10.6). Still, there are other considerations such as CSS text-shadow you might need to test before you make the final decision.
Next come the iPhone and iPad. Due to very high resolution screens (iPhone has a screen with 165 DPI, iPad 132 DPI), and more importantly the fact that both devices can be rotated, subpixel rendering is not used on these devices.
In a word, many variables can screw your perfect web fonts. Test as much as you can on all possible combinations of platforms. You never know what will happen. Plus, specify a metric-compatible, web-safe fallback in case the clients do not support web fonts and your beautiful design won’t be screwed up by a font with different size.