Web Safe Font Cheat Sheet v.2

May 25, 2010 by James Brocklehurst | 26 Comments

Here is the second release of the Web Safe Font Cheat Sheet, which includes updated statistics, better printability and a quick reference for using Google’s new Font API and Directory.

This article was originally posted in May 2010. You can find out about Version 3 of the Web Safe Fonts Cheat Sheet here

What’s New?

Updated Stats

As explained in the original article the main installation percentages are calculated by combining data from the ‘Web Fonts Survey’ produced by Code Style and NetMarketShare. As the source stats have changed, so have the overall installation percentages. I have rounded up the percentages to whole numbers, but for those of you who are interested, here are the actual breakdown figures:

Font	Win.	OS X	Linux	Total
Courier	99.71	98.87	66.14	98.6
Verdana	99.76	97.46	62.66	98.5
Times	99.47	98.02	65.19	98.3
Arial	99.33	97.74	67.72	98.2
Trebuchet	99.38	94.63	62.03	98.0
Lucida	98.76	100	77.86	97.9
Georgia	99.04	95.76	62.66	97.8
Impact	99	91.24	61.08	97.5
Arial Black	98.52	94.07	62.66	97.2
Tahoma	99.9	79.1	0	97.0
Palatino	98.76	78.81	0	95.9
Arial Narrow	88.95	90.11	0.71	87.4
Century Gothic	88.04	40.4	0	83.9

I have not yet included mobile operating system market share in these calculations (Net Market Share does) as there is so much variation in system fonts that it becomes next to impossible to factor in every situation. This is an interesting area for web designers however, and will become increasingly so as the iPhone/iPad, Android, Blackberry, etc, market share increases and a whole new can of typographic worms is released!

More Printable

Version 2 of the Cheat Sheet is plainer and this is in response to requests to make it more readable on domestic-level printers. I’ve tried it on a bog-standard office photocopier and it reads well, inkjets should also be fine but I would recommend using photo quality paper and the finest dpi setting.

All the content is included well within any margins that your printer may impose.

It is also A3 in size and realistically this is the smallest you should go for it to be of any use.

Google Font API

Last week Google announced a new method for embedding custom fonts on a web page which looks like it may very well revolutionise how web typography works.

I have included some of the best fonts on offer from Google’s Font Directory, along with the code required to utilise them. Not all the available fonts are there, as some either don’t display very well or don’t render cross-browser. More of this below.

I did want to include some suggested font stacks to use with these new fonts, but ran out of time. These should be ready for version 3.

The Google Font API in More Detail

The API is an exciting development because it uses the CSS @font-face property but solves four of the major issues that were holding widespread use of this method back:

1. Licencing. Google has created a ‘directory’ of freely available typefaces for anyone to use.

2. Downloading fonts. Google is hosting the fonts on their own servers and they can be accessed via a hotlink. End users will still have to download the font files, but these will be cached in the browser, so if they are in widespread use then in a lot of cases the user will have already downloaded them and they will be rendered almost instantly.

3. Multiple font formats for different browsers. Google deals with this all for you behind the scenes, meaning only a single line of CSS is now required to declare the font.

4. FOUT. The API includes some JavaScript that apparently alleviates the ‘Flash of UnStyled Text’ that occurs when a default font is displayed whilst the custom fonts is being downloaded.

Because it uses @font-face, all the benefits of this method are retained, so we can have selectable, resizable, cross-browser custom fonts without needing to resort to images, scripting or plug-ins. We can also use font stacking to create fallback fonts.

This is a huge step forward when it comes to web typography (and suggests how the mobile device issues might be overcome). It is in Beta stage however, and not without it problems.

Designed for the Screen?

The main issue as it currently stands is that the choice of suitable fonts is limited. In particular, we see some major problems arise when viewing the current selection of fonts in a browser that doesn’t anti-alias text. This applies mostly to those using Windows XP which does not have ClearType turned on by default. According to Net Market Share XP currently occupies 63% of the market so this represents a significant number of end users.

Here are some grabs from Google’s own Font Directory as rendered in IE7 without any ClearType anti-aliasing:

IM Fell Aliased

Tangerine Aliased

Now I know that any self-respecting designer wouldn’t consider using an overtly stylised typeface for anything other than headings, but even at the larger sizes these fonts render poorly. Other fonts, such as Josefin Sans Light don’t even work well with anti-aliasing at the smaller weights.

Why do Verdana and Georgia work so well as body text? Because each weight was crafted pixel-by-pixel to look good on the screen. By contrast, most, if not all of the current typefaces in Google’s directory look okay when printed, but have not been designed with screen display in mind. Considering the purpose for which they are being intended, this is a mind-bogglingly daft oversight.

It will only be a matter of time before this get resolved and some much more suitable typefaces enter the directory. But perhaps as a community we can collectively nag Google to get this right..?