By: Alex Walker

April 22nd, 2009

Reader Rating: 9

It’s a sad and mournful sound: that howl you hear from a graphic designer the moment they come to understand that they can’t simply choose just any font when working on the Web. Yes, type control has always been one of web design’s great limitations, in particular font choice.

Over the years there have been sporadic stumbles forward but we’re still waiting for that great leap. There are probably four schools of thought when it comes to text replacement: let’s have a super-quick recap of the current options available before taking a look at what you can do with the newest player in town, cufón.

This article was originally published in Issue #58 of the Design View [1]. Subscribe now [2] to get it in your inbox!

Classic Image Replacement

Classic image replacement (CIR) is the term I’ll use here to describe a collection of related techniques. It was the first true attempt to replace standard HTML text with a method without styling limitations.

Most techniques make use of CSS background images in place of the HTML text, which was either hidden using CSS sleight-of-hand, or obscured behind spans containing the background image.

Pros:

• Low-fi to implement, use, and view

Cons:

• Most methods have some kind of accessibility problem
• Multi-line text flow is usually an issue
• It’s problematic to produce new images for every heading
• Server-generated images are required when used with dynamic content
• Limited caching and reusability
• Non-scalable

A few years ago Dave Shea wrote the definitive rundown on the different flavors of classic image replacement, [3] which you should read if you’re considering CIR. Although it’s still seen occasionally (CSS Zen Garden is a prominent example) CIR’s drawbacks tend to mean it’s a technique in limited use in 2009.

sIFR (or Scalable Inman Flash Replacement)

Back in 2004 [4] Mike Davidson, Shaun Inman, and Mark Wubben came up with the first real breakthrough for type lovers—scalable Inman Flash Replacement. [5]

The technique relied on Macromedia (now Adobe) Flash’s ability to securely embed fonts within a Flash movie. JavaScript was then used to substitute out your HTML text for the SWF movie containing the styled text. Clever stuff, really.

Five years on, sIFR [6] is a mature robust technique in its third incarnation and is the default technique when it comes to customizing text. Many of sIFR’s early performance and accessibility issues have been moderated or even removed—text is selectable and linkable.

The biggest issue remains its reliance on both JavaScript and Flash to work. Although many advocates will argue that the percentage of users without Flash is insignificant, iPhone’s current lack of any Flash support puts a question mark over this technique for many.

The other drawback for some developers has been the requirement for the Flash authoring software. This has been addressed with sites like sIFRVault [7] now offering a selection of pre-embedded fonts for download.

Pros:

• practically limitless on font choice
• secure font embedding means fewer licensing issues

Cons:

• requires the Flash authoring software to embed the original font file
• hacky and highly complex translates to multiple points of potential failure, including browser version, JavaScript, and Flash support
• potential performance issues on older, overworked, or low-spec systems

In short, depending on who you listen to, sIFR is somewhere between a pragmatic solution to a flawed system and a convoluted, dirty hack.

@font-face

A long time ago in a galaxy far, far away they had perfect font support and they used @font-face.

In that glorious world, birds twittered gaily, the sun shone warmly, and designers attached fonts to their page with a single line of code and without fear of licensing repercussions.

Unfortunately we don’t live there.

The theory behind the @font-face declaration is rock solid and it’s been available in various forms since 1998. Simply attach the font to your page using the @font-face CSS like this:

@font-face {
 font-family: Echelon;
 src: url('echelon.otf');
}

Then just call on it using the font-family declaration:

h3 {
 font-family: Echelon,sans-serif;
}

That’s the easy part. The problem is that the act of making the font available on your server violates most end user licensing agreements.

Microsoft has promoted and supported an embedded font format called the Embedded OpenType (EOT) [8] since the days of IE4. Producing EOT font files from TrueType fonts is simple via a free, client-side application called WEFT [9].

EOT would be a very workable solution if it had any support outside Internet Explorer. Unfortunately, there is none.

Pros:

• elegant and simple to understand and implement
• graceful degradation as older browsers generally ignore the @font-face declaration

Cons:

• serious licensing issues exist with unembedded fonts
• currently only works in Safari 3, but possibly Opera and Firefox in the near future
• there’s been speculation that @font-face could expose users to viruses attached to downloaded fonts

So that was the state of play before vector text came along.

Vector Text: typeface.js and cufón

The most recent method of text replacement borrows some ideas from sIFR but manages to avoid its reliance on Flash. Instead, both typeface.js [10] and cufón [11] are slightly different takes on the same basic idea: using JavaScript to replace HTML text with canvas elements that render the text in vector format.

Each method requires you to convert your font into a vectorized JavaScript file using their free online tools. Happily, this is a relatively painless process. These vectorized fonts are then linked to your page, rendered to a canvas area, and swapped into your page on-the-fly when JavaScript is available.

Pros:

• less technology-reliant than sIFR (no Flash requirement)
• degrades gracefully

Cons:

• JavaScript-reliant
• unclear licensing issues for many fonts

Of course, sIFR advocates would argue that surely anyone using a browser modern enough to support the canvas element is likely to handle Flash files too.

This is true enough in all but one important user case—at this time no iPhone or, for that matter, Android phone can render Flash content. That is a sIFR showstopper for many developers. The canvas element, however, already has excellent support in WebKit, the rendering engine which powers Safari.

Trying on cufón

Okay, let’s look at a quick example of using vector text in a design. I’m going to go with cufón here because it’s a marginally smaller file, but most of the key concepts apply to typeface.js [12] too.

I’m going to start out with a rough blog concept [13] that makes no attempt to customize or replace the headers. Inevitably some users will browse without JavaScript, so your page still needs to work nicely sans groovy fonts.

Step 1: Grab cufón

Download a copy of the cufón script and attach it to your document. This file handles all the swapping, scaling, positioning, and styling of your type:

<script type="text/javascript" src="cufon-yui.js"></script>

Step 2: Convert your font

As with Typeface JS, cufón needs you to convert your file into the vectors it uses, but this is a free and easy process. Simply upload your font—TrueType (TTF), OpenType (OTF), Printer Font Binary (PFB), and PostScript fonts are supported—and their generator will give you back a new JavaScript file.

Obviously this is a good time to consider the licensing restrictions. While each type foundry takes its own view—often requiring a new license for each server or site—Adobe have been clear in stating their position:

That makes any and all Adobe fonts you own (such as Albertus, Bodoni, Caslon, and so on) the no-brainer choice for trialling this method.

Once you’ve selected and uploaded an appropriate font, you’ll be presented with a JavaScript file with a name along the lines of “your_font_400.font.js”. This file will need to be attached to your page after the cufón script. For the example, I’ve converted and attached two fonts—Pointy [14] and AquilineTwo [15]:

<script src="Pointy_400.font.js" type="text/javascript"></script>  
<script src="AquilineTwo_500.font.js" type="text/javascript"></script>

Be aware that there are two checkboxes on the generator that must be checked before it will allow you to proceed: one to confirm that the EULA of the font you’ve chosen permits font embedding, and the other to confirm that you’ve read and understood the converter's terms of use. Make sure you find them.

Step 3: Target the headings to replace

Let’s be clear: all text replacement methods (besides @font-face, arguably) are designed to replace heading text only. Replacing slabs of body text will be slow and counter-productive. We’ll stick to replacing headings only.

To replace any heading you simply use cufón’s replace function to target the element, and then define the font with a fontFamily. In the example below, I’m replacing all h1s and h2s with Pointy, and h3s with AquilineTwo:

<script type="text/javascript">  
 Cufon.replace('h1', { fontFamily: 'Pointy' });  
 Cufon.replace('h2', { fontFamily: 'Pointy' });  
 Cufon.replace('h3', { fontFamily: 'AquilineTwo' });  
</script>

Easy.

Step 4: The IE fix

As is often the case with Internet Explorer, we need to add extra code to make it work in that browser. Unmodified, IE users will see the original text load, followed by a visible flicker before the text is replaced. Thankfully the fix is easy, if slightly ugly.

Immediately before the closing body tag you need to add the following script element:

<script type=”text/javascript”> Cufon.now();  
</script>

Add this line and give your page a test.

As you’ll see in the demo page, [16] the resulting render is quite fast and clean on most systems.

Cufón objects take their position from your CSS and automatically inherit any font-size, font-style, font-weight, line-height, text-shadow, and word-spacing values. Very cool stuff.

You’ll also see that each word is a separate, transparent canvas, allowing backgrounds, images, and other text to show through, and words to flow freely from one line to the next.

Is there a downside? Well, text selection seems to be a problem, although fixing it appears to be a priority for developers. I also ran into the occasional overflow issue and what seemed to be sizing inconsistencies. A full list of known problems [17] and supported browsers [18] can be found on the cufón project site—if you keep an eye on that you’ll be the first to know when those issues are fixed.

But all considered—this is new, raw, and a bit experimental still—cufón is an exciting and really promising development for web typophiles.

[1] http://www.sitepoint.com/newsletter/viewissue.php?id=5&issue=58&format=html
[2] http://www.sitepoint.com/newsletter/archives?id=5
[3] http://www.mezzoblue.com/tests/revised-image-replacement/
[4] http://www.mikeindustries.com/blog/archive/2004/08/sifr
[5] http://www.mikeindustries.com/blog/sifr/
[6] http://wiki.novemberborn.net/sifr3/
[7] http://www.sifrvault.com/
[8] http://msdn.microsoft.com/en-us/library/ms533034.aspx
[9] http://www.microsoft.com/typography/web/embedding/weft3/
[10] http://typeface.neocracy.org/
[11] http://wiki.github.com/sorccu/cufon/about
[12] http://typeface.neocracy.org/
[13] http://www.sitepoint.com/examples/cufon/
[14] http://www.dafont.com/pointy.font
[15] http://www.abstractfonts.com/font/11569
[16] http://www.sitepoint.com/examples/cufon/index2.html
[17] http://wiki.github.com/sorccu/cufon/known-bugs-and-issues
[18] http://wiki.github.com/sorccu/cufon/browser-support