Custom Web Fonts: Pick Your Poison

Early in every web designer’s experience is a crushing moment of realization: the moment you discover that you can only use a small collection of fonts on the Web—and that all the good ones have already been used to death.

“Hooray!” thinks the naive Web newbie, checking out the font-family property for the first time. “I can spend the afternoon picking the font that perfectly reflects my personality for my new blog!”

And yes, sure enough, you can stick any font name you like in your CSS, and your browser will use the font on your system to display it:

.post {
  font-family: Papyrus, sans-serif;
}

The problem is what everyone else sees when they visit your site. If they don’t happen to have that font that is “just so you!” installed on their own system, they’ll see a generic font, most likely a downright boring one like Arial or Helvetica, instead.

Back in 1998, CSS2 proposed a solution to this in the form of the @font-face at-rule, which in theory would let you define custom fonts that would be downloaded by the browser from your web site:

@font-face {
  font-family: Papyrus;
  src: url(/fonts/papyrus.ttf);
}

On the surface, @font-face seems like it would be a godsend to web designers. So why has no meaningful support existed for it until very recently? Read on to find out…

First on the Scene

The problem with custom fonts is that fonts are not free. They are a lot of work to design—especially the ones that contain most of the characters available for use on the Web. Consequently, the vast majority of fonts (yes, even the ones that came with your computer) are licensed under terms that describe how they can be used.

Assuming you came by them honestly, you are allowed to use all of the fonts on your computer to design things from Word documents to logos on the Web, and you can do whatever you want with those things—give them away, or sell them for money—but you can’t give away or sell the font file itself.

This presented a problem for the first browsers that added support for custom fonts. Microsoft Internet Explorer 5.5 and Netscape Navigator 4 both had to tiptoe around the legal issues by developing their own font file formats that enforced the restrictions spelled out in font licenses.

Netscape 4 eventually died off, of course, and was reborn as Firefox, which has no custom font support. Internet Explorer, however, still supports custom fonts in Embedded OpenType (EOT) format today. Nobody uses it, however, because a) it’s IE-only, and b) none of the font companies have said it’s okay to distribute fonts in EOT format, either.

Apple Leads a Renaissance

The Netscape/Microsoft stalemate left designers skeptical about custom font technologies, and they got used to working with Verdana. For a while, it seemed like text on the Web would forever look the same.

Then, late last year, Apple announced that it was adding support for @font-face to Safari, and that it would work with plain, old TrueType font files—just like the ones designers collect in the hundreds and thousands! Would other browsers quickly follow suit?

In March 2008, Safari 3.1 was released with great fanfare. In its marketing for the launch, Apple boldly touted the fact that designers could “use any font they want to create stunning new websites using standards-based technology.” This announcement seemingly ignored the licensing terms of almost every font in the world—including Apple’s own fonts! Font designers were outraged.

The other browsers aren’t rushing to repeat Apple’s mistakes, but Apple has stirred up enough renewed interest in custom fonts for them to take a second look. In response, Microsoft has renewed its commitment to Embedded OpenType (EOT) format by opening it up for implementation by other browsers, and submitting it to the W3C for standardization.

One major font producer has announced its support for EOT, and has launched a site to lobby other producers to do the same.

Embedding vs. Linking

The big difference between linking to simple TrueType font files the way Safari allows and using Microsoft’s EOT format is that EOT can effectively “embed” the font in your web site. The EOT format ties the font file to your site’s domain name(s), so that it cannot simply be downloaded and re-used on another site.

This is effectively the same thing that happens when you use a custom font in a PDF file, or Flash movie. In all these formats, a motivated hacker could extract the font data and reassemble it as an unrestricted TrueType file, but the font data is distributed in a package that makes clear that such use is not allowed under the license. Font embedding is not about preventing piracy, it’s about making it clear that redistributing a commercial font is piracy.

Web designers, font producers, and browser vendors are now joining the debate over which approach to custom fonts makes the most sense for the Web. On the one hand, many designers argue that font producers should trust us to do the right thing. We don’t need a special embedding format for the images we use on our sites, so why do we need one for fonts?

On the other hand, font producers consider a font file to be a software tool for creating content, not content itself. Just as you aren’t allowed to distribute Microsoft Word to let visitors to your site view the Word documents you publish there, you can’t publish a raw font file to enable people to view content designed with that font.

Many web developers believe that embedding formats like EOT amount to Digital Rights Management (DRM), a technology that has proven disastrous to the music industry. Some have even suggested that the Web can do without commercial fonts entirely, and that we should make do with free fonts. It turns out that even popular “free” fonts like those created by Ray Larabie come with licenses that limit how they can be distributed. Larabie had this to say when discussing Safari’s font linking approach:

When it comes to my freeware fonts, I’m more reluctant to allow them to be used that way.

On his personal blog, Microsoft’s Chris Wilson has weighed in with a pragmatic analysis of the situation: Commercial font producers will never agree to allow font linking as supported by Safari, and open source fonts are unlikely to stack up in terms of quality or variety anytime soon. If we want to use commercial fonts on the Web legally, some form of embedding must be used, and EOT is the only open format for font embedding currently on the table.

What do you think? Should other browsers implement Microsoft’s EOT format, or should we push for Safari-style font linking, no matter what font producers say?