Here is the second release of the Web Safe Font Cheat Sheet, which includes updated statistics, better printability and a quick reference for using the Google’s new Font API and Directory.
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:
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!
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.
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:
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 look questionable. 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 an unusual 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..?
Download the Web Safe Font Cheat Sheet v.2
Any suggestions for future releases are welcome in the comments.
This is a version of an article that was originally published by James Brocklehurst on www.mightymeta.co.uk
No related posts.