Fixing Fancy Font Frustrations

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. Subscribe now 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, 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 Mike Davidson, Shaun Inman, and Mark Wubben came up with the first real breakthrough for type lovers—scalable Inman Flash Replacement.

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 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 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) since the days of IE4. Producing EOT font files from TrueType fonts is simple via a free, client-side application called WEFT.

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.