Web Directions Conferences for web and digital professionals

The return of font embedding to the web?

Sadly, quite a bit of what I wrote in this article is based on out of date information, and on my own testing that had a fatal flaw. I’ve left the article as it is, and added corrections inline

Most web designers and developers will be familiar with Image Replacement techniques, pioneered by early CSS guru Todd Fahrner [1] (FIR or Fahrner Image Replacement technique), and subsequent attempts to address the usability, accessibility, and other concerns associated with it.

These techniques emerged to address a significant problem with web design – it was not possible to embed specific fonts in a web page. So developers you could either rely on a small number of standard fonts on various platforms (and risk losing clients, or getting fired), or use images for text in some way. IR techniques definitely had advantages over using img elements, but were, and remain, far from ideal.

What a lot of people probably aren’t aware of is that even in Netscape 4 and Internet Explorer 4 there were ways of embedding fonts (or more strictly linking to font files online that browsers could then download and use for rendering the page.)

Uunfortunately, each browser had its own, proprietary format for doing so. Then, when Netscape 6 went open source, it could not open source the TrueDoc code it used to manage embedded fonts, and so font embedding, rarely used, was dropped in Netscape. While it persisted in Internet Explorer, developers very rarely utilized it.

CSS3 (and even drafts of CSS2 in 1997 and 1998) have long promised a standardized way of font embedding, using the @font-face rule. What many folks probably don’t know is that this rule is already supported in Opera 9.5, shipping versions of Safari for the Mac, Windows and iPhone OS, and is promised for Firefox 3.1., and well as IE6 and later.

Sadly, while support for @font-face was hinted at for Opera 9.5 and Firefox 3.1 (see my comments at #4 below) this is in fact not the case sadly.

There is a catch though. All the browsers other than IE support linking to TrueType font files. Microsoft supports only the proprietary EOT file format. They are however proposing to standardize Embedded Open Type (EOT).

While the way in which you specify fonts to embed in IE (using @font-face) is identical to how fonts are specified for the other browsers mentioned, Microsoft appears to be refusing to countenance supporting embedded fonts in formats other than EOT (specifically the extremely widely supported TrueType format, which the other browsers mentioned do support.)

There’s a lot of discussion (a lot of it heated and polemical, thankfully some more rational even if passionate) going on around these issues.

Bill Hill at the official IE Blog started the conversation with the announcement of a relationship between Microsoft and font foundry Ascender Corporation, and a discussion of EOT, and technical and legal issues around embedding fonts (it might have been more politic to separate the announcement from the discussion). This post included the announcement of the Font Embedding community, which describes itself as

A resource for designers, developers and typeface creators on font usage, technology and licensing issues

Joe Clarke, who’s spoken at a number of our events, and is never one to leave folks guessing what he is thinking, rather directly criticised the post (though the criticism is not entirely focussed on the issue of font embedding).

Chris Wilson, now platform architect of Internet Explorer, long time IE developer (and prior to that Mosaic developer (prior as in 1994)), co-chair of the HTML Working Group, and long time champion of web standards also posted a detailed discussion of the issues and his thinking. He writes

I’ve been clear on this to the CSS WG, so I suppose I should be here too – we (Microsoft) should NOT support direct TTF/OTF embedding, unless 1) there is some check that the font intended that use to be allowed, which I don’t think there currently is (as it needs to refer to the license agreement), AND 2) other browsers also implement a system that actually ENABLES commercial fonts – those that are allowed to be embedded, but cannot be legally placed directly on a server – to be used.

This is followed by a robust discussion, again often polemical, but well worth reading to get a sense of the issues.

Mozilla developer, Robert O’Callahan, recently posted on this issue, and discusses some of the issues around intellectual property protection.

The following is not correct, in the sense that it does not work for Opera 9.5 and Firefox 3.1 – only Safari 3.1 allows @font-face linking to TrueType files, and IE @font-face linking to EOT files. So the technique outlined should work, but only for those browsers.

But where do we stand as web developers? I consider it very unlikely that we’ll see Internet Explorer support formats other than something like EOT (Wilson says at one point “I don’t personally even care that much if that system is EOT as it is today”). But, there is some good news in all this. At least the same standardized approach to font embedding, using the @font-face rule works for all modern browsers. While I think it will be no small time until Internet Explorer supports direct font linking to formats like TrueType, all the major currently released browsers (IE6, IE7, Firefox 3.1, Opera 9.5, Safari 3) currently, or will shortly, support font linking or embedding using the same @font-face rule.

While it appears to be a return to the bad old days of IE/EOT versus Netscape/TrueDoc, is there in fact a way of using a single style sheet and serve embedded and linked fonts to all these browsers, so that each browser will use the intended font? Well, in fact there is. Here’s how.

@font-face rules specify a name for a font (you then use this name in font-family properties in the same style sheet) and a src where the font file can be found.

Instead of just using one @font-face statement, we’ll use two. The first will specify a font with an EOT file for Internet Explorer to use, the second a TrueType file for the other browsers to use.

The first @font-face rule looks like this

@font-face {
    font-family:"Fenwick";
    src: url(fenwick.eot);
  }

We specify a font-family name, in this case “Fenwick” (which happens to be the name of the font – but you can use any name you like here, it is merely a way of identifying the resource in the src property of the @font-face rule), and a src – which is a relative or absolute url to the font file.

(As an aside, I created these EOT fonts using the tool found at Font Embedding, and the fonts created are licensed to be used on web sites).

Next, we specify a second @font-face rule, for browsers that support TrueType file linking.

@font-face {
  font-family: "Matrix";
  src: url(http://www.westciv.com/CSS3Tests/matrix.ttf) ;
}

The font doesn’t look anything like Fenwick, I just happened to have it online – it’s a free font in the style of the Matrix movie’s credits.

Now, we just need a statement in our style sheet to associate these fonts with, for example, paragraphs. It’s probably one of the very first statements anyone uses in CSS

p {
    font-family: Fenwick, Matrix, san-serif;
}

When a browser comes to styling paragraphs with this CSS, it will first look for a font called “Fenwick”. Internet Explorer will use the font defined in the font-face rule, while the browsers which support @font-face, but not EOT, will use Matrix. Browsers which don’t support @font-face (Firefox 3 and earlier, Safari 2 and so on) will simply show a san-serif font.

You can see this in action here.

Yes, it’s a little bit of extra work, but it’s definitely technically possible (leaving aside licensing complexities) to now embed fonts for any contemporary browser. To me this is extremely exciting.

Now what we really need is for font foundries to realize the potential bonanza for them in licensing their fonts to be used like this, rather than focussing on the possible losses of people making unlicensed copies of their fonts.

[1] Todd, an original CSS Samurai, CSS working group invited expert, and designer with Verso, one of the early super star web design firms left the world of the web to run his own bike store in Portland Oregon. Plenty of times I envy him the wisdom of that decision.

We make events for the web professionals shaping Australia's digital future

Learn more about us

Going to #wds18 has given me inspiration to attend more conferences. Meeting tech folks like myself and learning from each other is pretty amazing!

Hinesh Patel Ruby and React Developer

Join us in 2019:

  • Web Directions Design 2019

    Australia's design conference with the world's leading expert

    Melbourne April 11 & 12 2019

    Details
  • Web Directions Code 2019

    Australia's conference for JavaScript and Front End Engineers

    Melbourne June 20 & 21 2019

    Details
  • Web Directions Product 2019

    Australia's conference for Product professionals

    Melbourne August 1 & 2 2019

    Details
  • Web Directions Summit 2019

    Our legendary event. Two big tracks, one Product/Design, one Developer focused.

    Sydney November 2019

    Details