Typekit Cufon FLIR sIFR, Which web font system is best?

Print Friendly, PDF & Email

Breaking out from web-safe fonts

Times New Roman, Helvetica, Arial, Verdana, Georgia, Tahoma, Tebuchet etc., For the longest time, web designers were stuck with using so called “web safe” fonts. These are fonts that you find on most common operating systems, such as Microsoft Windows, Apple Mac OS, and various Linux distributions (distros). By sticking to these core fonts you can be pretty confident that your website is going to render in the way you intended, and that a serious typographical faux-pas can be avoided.

Breaking out of web safe fontsWe’re going to look at a few ways to introduce (with reasonable safety) some typographical variety into your website, along with the advantages and disadvantages associated with each method. It is important to understand, there is no “best” solution for everyone, but hopefully this article can help you explore the possibilities.

When Times isn’t Times

For anyone who hasn’t already cottoned on, web browsers rely on the fonts already installed on your PC in order to render them on screen. Even “web safe” fonts are not strictly the same from platform to platform. Times New Roman on a Windows 7 machine isn’t necessarily going to be the same typeface as Times Roman on an Apple Mac.

Depending on other factors (some people love installing lots of fonts), even the same font name on two installations of Windows might not be identical, especially if the default system fonts have been over-written with commercially purchased alternatives – so the differences in default tracking, kerning and other nuances may serve to create an inconsistent result – especially if you are using type at display sizes, and need finer control.

It should be noted that all of the methods we are looking at, offer excellent accessibility for text readers – even the Flash based sIFR. Also, and most importantly, you must ensure that you possess the relevant license for the font you wish to use before uploading it to a web server. Not all foundries allow the usage of their fonts on the web, so beware lest you find yourself on the wrong side of the law.

So, lets dive in and start looking at ways you can pimp up your web fonts!

sIFR – Scalable Inman Flash Replacement

sIFRMike Davidson created sIFR as an open source JavaScript and Adobe Flash dynamic substitution system. It is based upon the original HTML text-to-flash replacement pioneered by Shaun Inman. Now several years old, it filled a gap for many, and continues to be used by many.

You can read more about sIFR at the developer’s website http://www.mikeindustries.com/blog/sifr

  • You can effectively embed just about any font you own (not just Truetype) by creating your own flash “font library”.
  • Final output looks as beautiful as any Flash generated typography.
  • All files can be retained locally on your server – no links to external service providers are needed to render your fonts.
  • Harder to configure due to the requirement to build the Flash font library.
  • sIFR needs JavaScript and the Flash plugin to work. If either is disabled or missing, the reader’s browser will fall back to traditional CSS based styling.
  • sIFR is not ideal for body copy due to the processing requirements. Although this is not such an issue with today’s machines, it’s far from ideal for slower machines.
  • Being flash based, sIFR may be vulnerable to add blockers, and other browser plugins that block Flash content. Oh, and of course, Flash won’t work on current iPods, iPhones, or iPads.


FLIRFaceLift Image Replacement is similar in concept to sIFR, insofar that javascript is used to replace html text on the fly. I instead of replacing text with Flash, it is replaced with 32bit bitmap PNG images, generated on the fly via a server side PHP script. The results vary, especially with more elaborate fonts, depending on which PHP module is being used to generate the output (usually GD, but ImageMagick can give better results).

You can find out more at the FLIR website – http://facelift.mawhorter.net/

  • Does not require Flash to work
  • Any Truetype/Opentype compatible font can be used.
  • All files can be retained locally on your server – no links to external service providers are needed to render your fonts
  • Easier to set up than sIFR
  • Configurable via plugins and config php file
  • Relies on PHP to render the output – character spacing sometimes requires tweaking.
  • Places extra processing and caching load on the server – which can create large numbers of files.
  • The final output, being a bitmap, is not readable as text, and therefore reduces accesibility unless javascript is disabled by the user.


CufonCufón, once again, uses javascript to replace the html fonts, but in a far more elegant way. The initial step in using Cufón is to generate a proprietary font library, which is effectively an SVG font embedded in a javascript file.

Generating this file is a relatively painless process, requiring the upload of your desired  font from your computer to the Cufón website and choosing some options before it gets “Cufónised” and downloaded back to your computer as a compressed javascript file. This file is then placed on your webserver.

The rendering engine for Cufón involves 3 components. A core API, and two rendering engines, one for Internet Explorer (which almost directly reads the VML data from the javascript font library), and another for browsers that support the HTML5 <canvas> element. Both renderers are very efficient and fast, and simple to install.

Cufon can be found via the project website – http://cufon.shoqolate.com/generate/

  • Client driven – no extra burden on the server other than to download the initial Cufón framework.
  • Able to vary the quality/speed ratio of the font library file’s produced.
  • As fast as your browser can render.
  • Reasonably screen readable (although see below) by sight impaired.
  • Any Truetype/Opentype font can be used.
  • All files can be retained locally on your server – no links to external service providers are needed to render your fonts.
  • The basic installation only allows fonts to be assigned to basic html tags, and relies on external selector engines, such as jQuery, MooTools, Prototype or Dojo to assign fonts to other selectors – not a biggie, and is well documented.
  • Generates a lot of extra DOM objects (specifically <span>) on the fly, which has caused issues with various screen readers, making accessibility a little more problematic. Again, not a show stopper, but not perfect. See http://www.paciellogroup.com/blog/?p=299 for more details on AA accessibilty status and Cufón.


TypekitTypekit leverages the @font-face CSS rules that despite having been bounced around for almost 10 years, have only recently been supported in a consistent way by the big browser developers. @font-face is a major step forwards in many ways because instead of trying to patch a gaping hole in the capability of web browsers, it has aimed to actually fix it by building the functionality that we have all been screaming out for.

Working with Typekit is about as painless as it gets – Which is why yours truly has opted to use it on this website. Once you have signed up with Typekit, (they even have a free account option with a respectable set of fonts available), you create a “Kit” – a Kit defines the domain name, and fonts to be used. Once the Kit has been published on the Typekit system, all that remains is to add a couple of lines of javascript to your site, and you’re away. Typekit can even automatically replace CSS selectors with your new fonts for you – or, you can use them in the normal font-family CSS rules as you would with any typeface.

The FOUT issue (Flash Of Unstyled Text) is one of the only real problems with using Typekit. This is due to the time taken for javascript to load up the new font data, and replace the fallback fonts on the rendered page. It’s a little unfair to level this argument solely at Typekit, because every other method also takes some time to do the switch (anyone with experence of sIFR will know this).

Typekit are very aware of this, and recently produced some extra documentation at http://gist.github.com/401726 on “Typekit Font Events”, to help developers control what happens at load time (most opting to simply not show anything until the system is ready – like the other web font substitution systems) – but it is impossible (currently) to avoid this issue.

However, this is probably outweighed by the superb accessibility this system offers, as no extra un-necessary inline <span> elements are introduced to achieve the results, keeping your markup semantically correct.

  • Does not alter your HTML markup – maintaining excellent accessibilty, and copy/paste ability.
  • Very simple to implement – and I mean SIMPLE!
  • Futureproof – as Typekit improves, so will the javascript they put on your page – minimising future maintenance worries.
  • A growing library of legally available fonts, so less hassle for designers.
  • At $50 a year for unlimited domains and fonts, and 500,000 page serves a month, it’s unlikely to break the bank. I was going to put this as a disadvantage, but come on… fifty bucks!
  • Relies on font data stored externally (albeit on super-fast, geographically dispersed sources).
  • Hiding the base content until the javascript switch has taken place needs to be coded in on top the default install.

In Conclusion

For me, in terms of usability and long term planning, Typekit would seem to be the weapon of choice here. Most importantly, it does not need Flash, or extra server time to create “quasi-text” with bitmaps. It is readable by people with accessibility needs, and search engines get an easier time too, which is important from a business point of view.

Typekit’s use of @font-face is the most forward thinking solution, and I’m sure as time goes by it will develop into an even more elegant form of web font delivery. The main issue here is that the fonts are being loaded by javascript as part of the page loading process. The html elements are already rendered by the browser by the time that the new font is made available. This would still be the case, even if the font files were locally hosted, instead of streaming from Typekit’s servers.

The standard is going in the right direction, but fonts still need to be loaded before everything else so that the DOM has access to them as soon as it initialises – and this is going to require some further co-operative thinking between W3C, and the browser developers, and I’m sure it will come in time.

However, for the time being, and FOUT notwithstanding, Typekit is the one for me. Waiting an extra few hundred millseconds for the final typography to activate is a small price to pay for maintaining accessibilty.


No comments yet.

Leave a Reply

Bot test * Time limit is exhausted. Please reload the CAPTCHA.