The new Google Font Directory hosts a collection of Web fonts that can be used in your pages, effectively the same service Typekit offers, in conjunction with the Google Font API.

Last year, I trialled Typekit and posted a brief summary of its strengths and weaknesses as compared to existing stop-gap font replacement technologies sIFR and Cufon. The Google Font API shares some of the cons I listed in that article, with the crucial exception that all fonts within the Font Directory are entirely free to use.

It’s nice to see Typekit co-operating in the venture, though I do wonder how they plan to differentiate their pay-for service from Google’s free one, once the directory has matured and a few bugs I experienced while testing IE8 are ironed out. The API is incredibly easy to use, and the five-minute tutorial is well worth following.

I’m sticking with Cufon for now, but it’s massively encouraging to see Google putting their considerable weight behind this technology.

To explain: fonts look much better on screen when anti-aliased, a process which operating systems perform automatically to smooth the edges of graphics and text to prevent flicker and jagged edges. As ever, Wikipedia has a much more comprehensive article on font rasterization than I could ever describe. Some designers might not even be aware that the pixel nightmare known as Non Anti-Alias text even exists (especially if using a Mac, as Apple’s OS has always had a pretty solid system for dealing with fonts). However when designing for the web you need to be aware that older browsers don’t offer Anti-Alias *cough* IE6 *cough* and will present all text as basic rasterizations. This is just one of the (many) hazards of producing online work, you have little control on how it will be viewed.

However when a website/emailer etc. is being designed, any visuals a client will see will be flat graphics, or maybe simple click-throughs, so the designer has total control over how any text will be displayed. The question then is this: Is it better to present a visual of the work as you would LIKE it to be seen, or to prepare them for the worst by showing them how it will render with Non Anti-Alias text?

For me the decision comes down to the context it’s being presented in. For pitch or speculative work I think it’s necessary to show your type at its best, make everything appear as in a perfect world, where everyone uses Firefox and Typekit has a global reach. However once you get down to the nitty, gritty, hashing out of usability of a site/page, being prepared to accept that sometimes things will be beyond your control and the client needs to be made aware of this, might be the best course of action.

Of course there are good, practical reasons why type online is so restricted. For one thing it was never originally meant for designers to be let loose on. For another digital type has progressed at leaps and bounds, but whilst online stores like Fontshop and MyFonts put literally thousands of variations at your fingertips, there has been no co-ordinated effort to bring these advances to the internet in a consistent and accessible way.

For a while people struggled through with Flash headers and text-as-image or hacks like sIFR until there stepped forward CSS and the @font-face property opening up the whole spectrum of fonts to everybody. Of course this has led to some badly misjusdged type-usage online, and of more serious concern, copyright issues over how font files will be uploaded and potentially pirated.

Typekit, and others like it, might offer an answer. Now in almost-total-complete-launch stage, they’ve created an online type repository that designers can subscribe to and use to create secure and reliable web typography. And for those like me who are seriously code-challenged, it takes a lot of the stress and strain of building accessible and standards compliant sites!

sIFR and Cufon

The CMS-based websites we produce nearly always require some sort of dynamic text replacement to allow non-system fonts to be used as page or section headings. sIFR is often our only feasible option when:

1. the heading font license is restrictive
2. the heading font can’t be adequately rendered by a server-side technology
3. the design calls for text manipulation beyond Cufon’s capabilities

sIFR sidesteps any font licensing issues by embedding the font into an Adobe Flash file and allows for heavy tweaking and customisation, beyond what Cufon offers. sIFR also produces selectable text, which is a nice (if not completely necessary) addition.

Where it can be used, Cufon is a great solution. Unlike sIFR, there is no noticeable jump or flicker when text is replaced and it’s a relatively small Javascript package to include.

The beauty of Typekit

sIFR and Cufon are both useful but are complete hacks. The appeal of Typekit is that is uses the @font-face CSS rule, which is the ‘proper’ way to do things. The Javascript you include with Typekit works around font licensing problems and the discrepancies in @font-face support between the different browsers. Of course, you are restricted to Typekit’s library of fonts, the growth of which will be key to its success.

Typekit isn’t free, which prompts the question of who manages the Typekit account. When delivering a site, we prefer to be completely transparent with hosting (our clients pay the Web host and any service providers directly) which is how we would handle a client’s Typekit account. Ideally, Typekit would receive a one-off payment for use of a font on a single domain (well, ideally it would be free!) which removes any need to justify an additional administrative overhead, just for the use of a particular font on their website.

Pros:

• complete typographical control with CSS
• works without images or Flash
• easy set-up

Cons:

• original font sometimes appears an instant before Typekit loads
• pricing model could be problematic for clients
• font file cannot be tweaked to reduce its size
• limited choice of fonts
• does not support Chrome or Opera

Chrome and Opera will hopefully be supported quite soon and Typekit must be eager to expand the font library with quality fonts as soon as possible. However, the first two cons are show-stoppers for me. Every site I’ve seen using Typekit suffers from a noticeable text replacement in Firefox and Internet Explorer. The closest web-safe font to the sans-serif Le Havre Rounded I tested was Arial. Below, you can see the Arial text that flashes up an instant before Typekit replaces the font.

Relating to a wider debate on Web typography, I noticed the differences between Apple and ClearType rendering meant that some of the library fonts had a completely different appearance on a Mac than on Windows. Of course this is nothing new, but slightly concerning given that Typekit allows developers to very easily use any font for any area of copy on a website. Below are some shots from the same Typekit configuration viewed on different browsers.

Safari:

IE (or Firefox with XP ClearType):

Firefox without XP ClearType:

Of course this is in no way a fault of Typekit, but worrying to think legibility and readability of standard web fonts may be shunned in favour of prettier typefaces.

Overall, I’d encourage any developer to try Typekit as it’s already a real alternative to sIFR and Cufon. I’ll be eagerly following its progress.