Web Fonts
31 Oct 2008With a gentle prod from Jon, I've been reading about the hot topic of web fonts. I have as many questions as answers, but I'm going to try to share what I've learned so far.
Jon provides a good history, and the short summary is that we've been stuck with a limited selection of core web fonts for quite a while, and font linking offers an opportunity to improve the situation by providing more options.
Font linking, simply referred to as web fonts in the CSS3 working draft, has been around for a decade, since CSS2. If you're a non-observant developer like me, you're probably wondering why this is still a topic of discussion. Isn't this a solved problem? Not quite. This excerpt from an article by Håkon Wium Lie explains the history pretty succinctly:
In 1998, CSS2 described a way to link to fonts from style sheets, and both Microsoft and Netscape added support for web fonts in their browsers. However, neither vendor supported the most widely used font format, TrueType. Instead, they each picked a different, little-used format with few tools to support it (EOT and TrueDoc, respectively).
In other words, the most popular browsers of the time supported using @font-face to link to a font. The only problem was that the font itself had to be in a particular format.
The distinction between web fonts, font linking, and font embedding seems important.
Web fonts is the term used in the CSS3 working draft and is also used to refer to font linking with @font-face as described in CSS2, but it is never specifically used to refer to linking to fonts in an EOT format. This restriction in usage gives us the two topics being debated:
- Linking to fonts in an EOT format. This is sometimes referred to as font embedding, because the font is tied to a specific location, such as an entire web site, a directory within a web site, or a specific page.
- Linking to raw font files, primarily TrueType or OpenType formats. This is sometimes referred to as font linking.
Font linking and web fonts are used interchangeably, and their usage is ambiguous. Sometimes they refer to the mechanics of the technology (which is format independent), and other times they refer to linking to raw font files, excluding EOT.
The reason web fonts are being talked about again is that WebKit (Safari) and Firefox (as of 3.1) support linking to TrueType fonts. If you're curious about the mechanics, Jon has an example using a font that allows linking. He links to the font (Fontin-Regular.otf) as follows:
@font-face {font-family: 'Fontin-Regular';src: url('Fontin-Regular.otf') format('opentype');}
You can specify any name you want for font-family (Jon chooses Fontin-Regular), and you use this name in CSS as you would any other font:
h1, h2, h3, p, td {font-family: 'Fontin-Regular', georgia, serif;}
Pretty easy, right? Yes, but so is downloading an MP3. It's when you start considering the rights of type foundries that things get a little more complicated. There are lots of free fonts available, but the Ascender Study of Free Web Fonts offers the following conclusion:
Out of the 4572 fonts tested, 4385 fonts (95.9%) failed one or more of the six tests that were performed.
Paraphrased, free fonts suck.
Type foundries are understandably concerned about font linking and are much more agreeable to font embedding, because it offers a solution to the problem of rights management. (Microsoft has submitted EOT to the W3C in the hopes of making it a standard.) It might not be the best solution, but there aren't many alternatives on the table. Bert Bos's summary of the debate is a good backgrounder and mentions a few options.
I can't help but see a similarity between this and PDO 2. After the PHP community shunned the major database vendors who were trying to find a compromise between their legal obligations and their desire to offer better drivers, the effort died, and very little progress has been made since. If you want to learn from our mistakes, try to appreciate the needs and obligations of those with the quality resources. In this case, it's the type foundries.
While I was researching for this post, I noticed a common theme in all of the security discussions: the focus is more about the promises being made than the strength of those promises. Jon doubts the strength of EOT (more precisely, he doesn't doubt its weakness), and I agree with his prediction:
Although EOT is not a DRM solution per se, it feels like one. If it achieves widespread acceptance, no doubt some clever soul will be reverse-engineering an OTF file from EOT before too long.
Perhaps people with fonts in an EOT format will simply convert them on-the-fly with online utilities:
@font-face {font-family: 'Precious-Font';src: url('http://eot2otf.com/?font=secret.eot') format('opentype');}
Similarly, scalability discussions raise questions. In the aforementioned summary, one of the arguments is that EOT is not scalable, and this argument is summarized as follows:
The argument was put forward that the best way to share a font is to share just its URL. EOT as described in the submission only deals with embedded fonts, i.e., each document or group of documents needs its own font resource that's bound to those documents. But when the license of the font allows it, it would be good to have just one EOT file that is linked from everywhere.
Is it just me, or does the solution seem less scalable than the problem? As empirical evidence, consider gravatars. Despite the fact that few people use them, the demand is very difficult to manage. Can you imagine a type foundry trying to deal with a popular font? Consider something as ubiquitous as the Baskerville typeface. (Wouldn't you hate to see the exquisite ampersand replaced with one from a default typeface due to the type foundry's scaling difficulties?) I guess it could be good for business, but I can't help but wonder whether this has been carefully considered.
One of the reasons Jon hopes to have more developers involved in the conversation is so that we can identify potential problems while this is still a topic of discussion. Now that I feel properly caught up on the history, I hope to spend some time digging into the details.