Chapter Fifteen: Web Fonts

For most of its history, the web has been a text-based medium. Despite this, the range of fonts available to web designers and developers has been severely limited. Unless a font is installed on a user’s system, a designer can’t use it, so we’ve been forced to rely on a small palette of fonts installed on both major web browsing platforms, Mac OS X and Windows. Despite the fact that both OS X and Windows come with dozens of installed fonts, the overlap between the two platforms is small. As we’ve seen, CSS does provide a mechanism for specifying a group of fonts so the browser has fallback options if a specific font isn’t installed. Unless we specify a group of fonts that have roughly the same default size, the legibility and appearance of the page can be markedly different depending on which font is available.

As a consequence, designers have several techniques that use images or Flash for text, while still attempting to maintain the accessibility of their sites. Such techniques, which we saw in Part I, fall short of really solving the problem. They produce complicated markup and—in the case of image-replacement schemes—greatly increase the complexity of production workflows, as each piece of image-replacement text must be rendered as an image before that image can be embedded or added via CSS. Every time the text needs to be changed, the image must be edited and re-uploaded—not to mention that linking to so many images can harm site performance. Flash-based image replacement techniques come with their own problems, not least of which is that Flash’s text-rendering engine is different from the browser’s text-rendering engine.

Even after text-replacement effects are achieved, they’re far from ideal. For image-based text, the text can’t be found by the user with the browser’s “find” functionality, and when text or the page is zoomed, the image either doesn’t zoom at all (with text zooming), or becomes pixelated (with page zooming). These techniques can also produce design problems: The replaced text, having been rendered by a tool such as Photoshop, or Flash, is necessarily rendered differently from all other text in the document, which has been rendered by the operating system. All in all, these methods aren’t really solutions at all, but their popularity speaks volumes about designers’ need for a wider variety of fonts.

The irony is that for the last decade or more—since long before the invention of techniques like FIR (Fahrner Image Replacement) and sIFR (Scalable Inman Flash Replacement)—most people have been using a browser that actually supports real font embedding, the ability to download fonts from a web server, and render pages with these fonts. So, why haven’t we seen this technology in use? Therein lies a tale.

A Brief History of Font Linking and Embedding

The release of version 4 of both Netscape Navigator and Internet Explorer marked a watershed in web development history. Both browsers introduced real-world (rather than experimental) support for CSS and support for something approaching what we know as the modern DOM—the two standards that have defined modern web design and development.

Both browsers also supported font linking. That’s right—in both IE4 and Netscape 4, it was possible for designers to use fonts that lived on a web server, rather than on each user’s machine. The catch? The two browsers used incompatible methods to do so.

Netscape 4 used TrueDoc, a format created by a font technology company called Bitstream. Internet Explorer 4 (and every subsequent version of IE) used the proprietary Embedded OpenType (EOT) format. Web developers, on the other hand, didn’t really use either. They never fully adopted TrueDoc, in part because when Netscape became an open source project as of version 6, it lost access to TrueDoc due to licensing complications. And although Internet Explorer still supports EOT, the format never caught on with developers, even at the height of IE’s popularity. Precisely why is difficult to say. EOT was and is a Microsoft proprietary format, a fact that may have made early-adopter web developers less likely to embrace the technology (it has subsequently been proposed as a W3 standard format, though it currently seems doubtful that it will become one). Perhaps more importantly, EOT files are complex and difficult to create, a fact that has discouraged developers from experimenting with them.

Whatever the particular reason—and despite a clear demand for more sophisticated typography on the web—font embedding has simply not taken off. However, due to recent technical, legal, and business developments, this may be about to change.

The Current Legal Situation

Before we delve into the technical aspects of using fonts served on the web, it’s important to understand the legal implications of such use.

Fonts, like a great many other creative works, are protected by copyright. In the absence of an express license to do so, fonts can’t be copied or distributed. Which almost certainly means that placing a font on a server and allowing browsers to use it to render web pages—without express permission to do so—is a breach of copyright. Remember that phrase, “express permission,” because it’s going to come up a lot.

When you purchase a font, you typically agree to an End User License Agreement (EULA). The terms of these licenses vary; commercial fonts are rarely licensed in a way that allows them to be used via font linking. Furthermore, although there are many “free” fonts available online, at least for alphabets used in Western European languages, in the absence of an express license to do so, you can’t legally upload these fonts to your server and use them for font linking. You can read an overview of the legal problems with free font licensing at TypeKit (blog.typekit.com/2009/06/11/when-free-fonts-arent-free), a service we’ll discuss in detail shortly.

The Current Technical Situation

Although IE has supported font embedding using the EOT format for over a decade, until Safari 3.1, no other modern browser supported font linking or embedding. With 3.1, Safari introduced support for font linking, for the TrueType and OpenType formats—the formats that operating systems use for fonts—but not the EOT format. Firefox 3.5 and Opera 10 beta also support font linking to TrueType and OpenType fonts, but again, not the embedding of EOT fonts.

So, are we back where we were in 1997, when each major browser offered competing, incompatible formats? Luckily, no. We can use a CSS mechanism that links to fonts in such a way that Internet Explorer will use EOT and other browsers will use TrueType or OpenType. Nevertheless, we must keep in mind that we can only legally use fonts when we have express permission to link.

@font-face and Embedding Fonts

The process of linking or embedding a font is nearly identical for all modern browsers. We do have to take into account the different formats those browsers support, but we can do so in a standards-based, efficient way.

The first step in the process is to specify a font name and source using the CSS statement @font-face. We can then use this newly named font in our CSS just as we would any other font. @font-face was introduced in CSS2 and is modified in CSS3. An @font-face statement defines the name of a font to be used in a style sheet, and the source of the font (a URL locating the font file on a server). Here’s how we’d define a font called “Blackout”:

We would then use this font for headings of level 1 in our pages like this:

You can think of the name in the @font-face statement as a variable—it doesn’t have to match the font’s file name on the server, but it’s the name we must use in our style sheet.

That’s it. Simple isn’t it? If you’re wondering why font linking has been used so sparingly, though, you’re about to find out the answer.

Embedding Fonts with Internet Explorer

Before we can embed a font with Internet Explorer, we must convert it to the EOT format. Because EOT files are “tied” to specific web pages, we can’t simply create an EOT file once and be done with it. Every time we create a new site—and depending on various factors, even when we add new pages to our site—we will probably need to create a new EOT file. Furthermore, there’s really only one way to create such files, and it’s not an especially pleasant experience.

Firstly, you’ll need Windows.

Yep. Well, technically, there’s a UNIX command-line utility called TT2EOT, which you can also use on Mac OS X, for those who are comfortable with such things. Otherwise, you’ll need to download the Web Embedding Font Tool (WEFT) from Microsoft, which runs only on Windows.

The WEFT tool takes a font file in a format like TrueType, and a web page, and creates the EOT file from that combination. By default, the EOT file won’t contain the entire font—it will contain a subset of the font’s characters, based on the contents of the web page you feed it. You can force the WEFT tool to make EOT files that contain the entire character set, which will result in larger but more maintainable files. WEFT requires that you give it a list of “allowed roots” or access URLs for the font. In other words, you must encode into the EOT file all the root URLs you want to use the font with. So, for example, you might need to use http://webdirections.org, http://www.webdirections.org—and, for good measure, file://c: so you can test your pages locally—as well as the addresses of internal test servers, and so on.

Once the EOT font has been created, you can upload it to your server and then use @font-face and CSS as described earlier, setting the src URL value to the location of the font file on the server.

Linking Fonts with Other Browsers

Because other (non-IE) browsers support linking to TrueType and OpenType fonts, the formats that operating systems also use, there’s no need to process these font formats in any way before using them with @font-face. We simply upload the fonts to a server, and create an @font-face rule that assigns the font a name and specifies the URL where the font is located.

We can then define two different @font-face rules defining two different fonts: one for Internet Explorer, and one for other browsers that support True-Type and OpenType formats:

and then our CSS looks like this:

We’ve defined a TrueType font, “Product”, and an EOT font, “Fenwick”. But we still have a challenge. Font files tend to be quite large—they may be several hundred KB per file (or more). If a browser downloads all the fonts defined by @font-face statements, it will download twice as many as it requires. (Safari 4 won’t download files with names ending with .eot defined in @font-face rules, but Firefox 3.5 will, and Internet Explorer will download TrueType and OpenType fonts even though it can’t use them.)

We can do two things to ensure that browsers download only the formats they support, and so improve the performance of our site. First, with our @font-face rule for non-IE browsers, we add a format hint (which is part of CSS3) after the src, like this:

Internet Explorer ignores any @font-face statement with a hint like this.

Hiding statements from Firefox and other browsers, however, requires falling back on trusty conditional comments, which we met in Part II. Because conditional comments work only in HTML, we can only hide the @font-face statement for IE from other browsers by putting it into a separate CSS file and then hiding the link to this file using comments, like this:

If the @font-face statement is in the head of a document—though, as we’ve seen, embedding CSS instead of linking to a separate style sheet is not generally recommended; instead, use something like this:

Challenges

Using these techniques with properly licensed fonts, we can design our pages using a much broader range of fonts than we have previously relied on. We can also avoid the hacks and attendant downsides of font-replacement techniques. Once a user’s browser has downloaded a font linked using the methods just discussed, text set in that font can be cut and pasted, zoomed without text pixelation, and so on—all things you can’t do with font replacement.

Still, as noted earlier, font files can be quite large, and each is an individual file. So unless they are cached locally, it will take some time for fonts to be downloaded and used to render a page. This raises a question: While a font is downloading, what should a browser do? Not display the text in those fonts on a page at all? Display it with substitute fonts? Both solutions can cause problems for the end user. If a large section of a page remains blank for seconds while a font downloads, readers may conclude the page is broken. The alternative—styling with one font, then switching to a second once it is downloaded—is potentially disorienting, since the text may shift around on the page to accommodate the size metrics of the new font.

Safari chooses the former approach and leaves large gaps where text will be when the font is downloaded. Firefox, Opera, and Internet Explorer all use the second approach, using a generic font, then swapping in the specified font once it downloads. Neither is ideal, but until connection speeds increase significantly, one or the other of these approaches will be required. (And with some effort, you can simulate either approach using JavaScript, thus forcing Safari to adopt the default-font-then-switch behavior, or making IE, Opera, and Firefox leave blank space until the font is downloaded.)

It’s not clear whether viewers will be too concerned about a change in font once the font is downloaded, though anecdotally, Safari’s approach of not rendering text until the font is downloaded does seem to confuse or disturb readers. In a year or two, we’ll have a much clearer picture of what behavior web users find acceptable.

@font-face Support in Contemporary Browsers

Mitigating the Problems

Given the usability challenges associated with font linking, it may make sense to restrict the use of downloaded fonts to headings and other non-body text. That way, the user—who is likely to be focusing on the main page content anyway—can begin reading immediately and won’t be overly distracted once the linked fonts download, since the text they are reading is likely to remain largely unaffected by the loading-in of the linked fonts.

Due to the performance problems we’ve noted, you’ll probably want to use as few fonts as possible—and, where possible, to use fonts with smaller file sizes. And, of course, make sure each browser downloads only the font formats it needs. (Sadly, you can’t simply zip your fonts.)

Fonts as a Service

Once @font-face began to be supported in Safari, Firefox, and Opera instead of only in IE, several groups spotted a business opportunity as a provider of “fonts as a service”—that is, of inexpensive, hosted, and fully licensed fonts that web developers can easily use. As of mid 2009, three such services have been announced: TypeKit, Kernest, and FontDeck. Full disclosure: I’m an advisor for TypeKit, and my blog posts on web fonts motivated the service’s founding. It’s impossible to know which of these services will succeed, it seems likely that services such as these will help developers surmount the legal and technical obstacles preventing them from linking to fonts and will thus hasten the arrival of widespread downloadable fonts on the web.

The Wrap

Now supported in all contemporary browsers, the use of downloadable fonts in web development is both technically feasible and practical. Legal challenges remain, but several new “fonts as a service” projects are poised to address this hurdle—plus, it’s increasingly likely that at least some foundries will see the revenue potential in font embedding and linking and will license their fonts for use in this way without the need to go via an intermediary.

Used judiciously, font embedding will offer a new sophistication long lacking in web typography. As with the blink element back in the 1990s, new typographical options will doubtless produce some dreadful sites, but despite that, the web will be the better for embedded fonts. Use them well, and your sites will delight your visitors—who have, after all, been wandering a typographical wasteland since the web was born.