About the Author

Chris Shiflett

Hi, I’m Chris: web craftsman, community leader, husband, father, and partner at Fictive Kin.


Font Linking

With a gentle prod from Jon, I've been reading about the hot topic of font linking. I have as many questions as answers, but I'm going to try to share what I've learned so far, and I hope you'll join the conversation.

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, also known 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.

I'm an unapologetic pedant, so 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 font linking is 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://shiflett.org/eot2otf.php?eot=Precious-Font.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. More to come soon.

About this post

Font Linking was posted on Fri, 31 Oct 2008. If you liked it, follow me on Twitter or share:

11 comments

1.Anonymous said:

Nice and interesting read, Chris. Thanks.

Mon, 03 Nov 2008 at 07:34:25 GMT Link


2.Jon Tan said:

Thanks for the mention, Chris. I'm looking forward to the follow-up. I think the hard-won experience of web app security people can help the type and design communities avoid mistakes that have gone before, and understand how to move forward.

Mon, 03 Nov 2008 at 09:44:52 GMT Link


3.Stelian Mocanita said:

Great reading Chris and congrats to Jon Tan as well. Never put much thinking into this and I didn't think of this problem much but now I am going to turn geek and put some more effort into it.

Great job guys.

Mon, 03 Nov 2008 at 09:47:16 GMT Link


4.Artem said:

Great post chris.

Flash has already been around the block when it comes to font embedding. Perhaps a similar solution could be introduced for web browsers? Nah.

Ultimately I feel that the flexibility of using any font that you want on a web page will never come to fruition.

There is no other medium that has standardized data like the web and thus scraping websites for fonts and reselling them on a foreign hosted server for $0.50 per font will be a piece of cake (just like google indexes images, but instead index fonts).

DRM has taught us that encrypting anything for re-use by a horde of distributers will not work as eventually someone will crack it open like piggy bank jar.

I'll be the first to say that a small list of standardized fonts is a good thing! The user knows exactly what to expect which is rule #1 of great usability.

Imagine what would happen if it took very little knowledge/effort to include any font on a web page. I'll assume you have all seen the amount of laziness/carelessness attributed to web design as a whole so I won't elaborate on that point.

With all of that said, here is my proposal...

Simply have each browser select 20-30 great quality free fonts and give the library a name like OFL (Open Font Library) or something like that. Make the library a standard and release it with every web browser distribution.

The font library will be open for download so any smaller browser engine will be able to adopt it.

This way we solve:

- the DRM issue since all of the fonts are free

- the usability issue since there are only a few handpicked fonts

- the standards issue since these are all shipped with web browser releases and can easily be adopted by other web browsers.

Mon, 03 Nov 2008 at 12:15:56 GMT Link


5.Dejan Kozina said:

Kudos to Ascender for their effort, but it seems to me that their report might be missing the point calling as 'failed' fonts for something that is not really relevant to the issue.

1) Missing hinting tables: hinting tables are a good thing to have in a font file, but if there is not one (out of three), well, so what? One will miss on the "better screen quality", but the thing will still be usable.

2) Windows 1252: big fail here, as Win1252 is definitely not the same as Latin-1 (aka ISO 8859-1). I didn't check what exact glyphs are stated to be missing, but they might have been looking at the wrong positions believing Win1252 == Latin-1.

More, the lower half of both Latin-whatever and Win-whatever are the same as good old ASCII, which contains a fair share of non-printable characters and control codes. Does someone really care if there is not a glyph for BEL, ACK or SYN?

BTW, the default best practice for I18N since the demise of NN4 is utf-8, but it gets no mention at all...

3) Mac Roman: see last point above. Mac Roman was a pain in the ... until OS-X, breaking I18N rendering right and left. Can't remember anyone lamenting its deserved demise - until this report. Can't think of anybody in web design who cares now.

4) No copyright string: might have a point here - if the string has been actually stripped away. But they call it failed even if the author placed the file in the public domain, thus making the font on purpose free to and for all.

5) No trademark: makes sense only if the font is a object of trade. I see many fonts by Laramie in the report - all marked clearly as 'freeware' in the Copyright string and with a blank trademark string. Where is the failure exactly with such a font?

6) Embedding restriction: calles 'fail' without explaining exactly what was wrong here...

Overall this could be an useful report - if they'd only make it anew (this one is dated 2006), this time checking for utf-8 and avoding the blunder with Win1252 (and, please, forget about Mac Roman - OS-X has been around since 1999 and it defaults to utf-8). As a "leading provider of advanced font products" they should't let such sloppyness be released with their name and logo on top.

Mon, 03 Nov 2008 at 13:22:20 GMT Link


6.Michael B Allen said:

Are the fonts Unicode fonts? If no, I fail to see the point in all of this. If yes, they could be rather large to download dynamically. Has this issue been explored?

Mon, 03 Nov 2008 at 17:54:51 GMT Link


7.Jon Tan said:

Hi Michael. What do you mean by a Unicode font? Do you mean fonts that include all 95,221 Unicode characters?

To answer you second question, as the article Chris linked to indicates, EOT and OTF can both have subsets depending on the unicode range required which can reduce the file size significantly. For example, to the 32KB (OTF) or 10KB (EOT) in the article.

Tue, 04 Nov 2008 at 09:19:37 GMT Link


8.Brad Touesnard said:

You made a really good point drawing the parallel between font linking and MP3s. In fact, I see font linking being embraced by the design community just as MP3 has been embraced by podcasters and independent musicians. Sure, like MP3, font linking will be abused and unlicensed fonts will be downloaded and used. However, like the music industry, I think the transformation of the type industry is inevitable and either the type foundries act quickly and get on board, or they go the way of the record labels doing too little too late and wither.

Wed, 05 Nov 2008 at 23:36:42 GMT Link


9.Dor said:

Hi Chris,

I've read the article but couldn't understand what's the problem with the following property in CSS:

src: url('http://shiflett.org/eot2otf.php?eot=Precious-Font.eot')

It allows flexibility in choosing the font that the developer wants.

About the copyrights, well it depends on the font itself (if it's free).

I mean that we can use fonts just like we use images in our web page.

Sun, 25 Jan 2009 at 19:41:15 GMT Link


10.Derrick said:

thanks for the post. embedded fonts are the next huge wave of design, as they can really set a design apart. i am soo tired of Arial and Verdana!

Web Design by Webcore Interactive

Thu, 18 Feb 2010 at 22:46:04 GMT Link


Hello! What’s your name?

Want to comment? Please connect with Twitter to join the discussion.