Falling Leaves: the Ardes blog
Ray Drainville

Well! We certainly haven’t updated in a long time. Happily, the reason is that we’ve been busy, in fact the busiest we’ve ever been.

I thought I’d go over one aspect of a site we developed, as the subject isn’t particularly well-covered on the web. The subject is font embedding, also known as web fonts, which has been around as a technique—although rarely ever implemented—since the original “browser wars” of the late 1990s. As this is a real-world example, I can provide information about font rendering, display & other bugs and finally tool usage.

What is font embedding—why don’t we see it used?

First, let’s define what we’re talking about. If you search for “font embedding” or “web fonts”, you’ll get wildly differing instructions because people are talking about different things. For instance, many people will use these terms to explain how to access standard fonts on a computer via the font-family declaration in CSS. Some older pages may describe using font-face tags inline to change the usage of fonts—that is, to use Arial instead of Times New Roman for a passage of a page. Both of these techniques refer to the fonts installed on the end-user’s computer & as such pick from the list of likely fonts to use: Helvetica, Arial, Times New Roman, etc.

Neither of these is what we’re talking about, however. Back in 1998, in the CSS Level 2 recommendation, the W3C discussed font downloading as a technique to use fonts that the end-user doesn’t have installed. In this case, the browser downloads the font for use on the site in its cache—once you’ve browsed away from the page or site that uses font embedding, the font is no longer used & you cannot access it for use on your system. While the W3C discussed different formats that could be supported, Netscape & Internet Explorer opted for competitor formats that were, essentially, encrypted, PFR (TrueDoc Portable Font Resource) & EOT (Embedded OpenType), respectively. Because the font is, essentially, embedded, this is why I’ve decided to opt for the term “font embedding”.

Developers’ responses to this innovation was best described as muted. In a period where the two browsers were going hammer & tongs at each other & supporting wildly different tags & formats, developers had their hands full supporting far more basic things than font embedding. Font embedding withered on the vine, despite some attempts to revive it.

WebKit—the engine that drives Safari, among other browsers—listed font embedding as a new feature in October 2007. This has spurred re-interest in the use of font embedding, as Safari & Internet Explorer now support it.

Here endeth the history lesson.

Why use font embedding? A practical example

So, back to us. We had a client who had a pre-existing website that was rendered entirely in images. Updating the site’s content was, obviously, a nightmare & moreover, search engines knew nothing about any given page’s content. They contracted us to make it editable. Accordingly, we developed a lightweight CMS for them to handle the content.

However, they also wanted us to use their typeface, based upon VAG Rounded Thin. What were the options? Hmmm. Hmmm. Hmmm.

The options for displaying non-standard fonts

It turns out that there are four options. They’re listed here from least desirable to most desirable (in this example):

  • Image replacement. Here, they’d type their text & we’d create an image that would be displayed in place of the text. This technique is known as image replacement. This wasn’t optimal because the clients wanted to be able to change the content on the page & make it viewable by the end-user.
  • font-family. We could display the font using the font-family CSS declaration & hope that the end-user had the font. This was deemed undesirable because of its unpredictability.
  • sIFR. sIFR makes use of Javascript to replace text with a version of the desired font rendered with the ubiquitous Flash plugin. We seriously considered using this, but heavy usage (say, for every glyph on a page) makes it very slow. As a fallback, we considered using sIFR for headlines & other important items.
  • Font embedding. It’s a W3C standard & has been so since 1998. What could possibly go wrong?!

And so we began our odyssey into the world of font embedding and undocumented bugs & features. Join us as I gather up the hair that fell from my scalp & attempt to glue it back on.

Font embedding practicalities: what works, what doesn’t, & why

There are few pages on the web that give you much information about font embedding. Moreover, even though the idea’s been kicking around for a decade, because few have ever really tried to exploit it, the featured is often half-baked in implementation.

So, looking at Safari & Internet Explorer, we know that we can use TrueType fonts & EOT files, respectively. You declare font embedding in your CSS thus:

  @font-face {
    font-family: "VAG Rounded Thin";
    font-style: normal;
    font-weight: normal;
    src: url('vag_rounded_thin.ttf');

That alone won’t work, however. You also have to declare where it’ll be used:

  body { font: 1em "VAG Rounded Thin", "Trebuchet MS", sans-serif; }

And behold, in Safari, it works:

Font embedding sample seen in Safari 3.1.2

This doesn’t work in the most popular alternate browser, Firefox:

Font embedding sample seen in Firefox 3.0.1

This is why, in this case, we opted for Trebuchet as a fallback above in the body declaration. It’s similar enough to VAG Rounded Thin that the difference isn’t jarring. For your own work, I recommend that you look for the common font most similar to the one you want to embed. Also, because font metrics vary so dramatically from font to font be very careful in your CSS declarations. I strongly recommend using Eric Meyer’s “CSS Reset” to give yourself as solid a foundation as possible.

Incidentally, font embedding also doesn’t work in Opera:

Font embedding sample seen in Opera 9.5.2

Font embedding in Internet Explorer

Now for Internet Explorer. You have to use a tool to convert your TrueType font to the EOT format. Microsoft provide WEFT, a free tool for doing this. It’s Windows only & I guarantee that its interface will take you back to the days of Windows 3.11.

WEFT works, but there are caveats. It would ideally like to attach the embedding information directly to your pages. This is really problematic if you’re using a template-based system—which we were, as we developed the site using Ruby on Rails. What you have to do is tell WEFT to ignore your site & place the EOT file onto your hard drive.

Because its intention is to restrict unauthorised use, WEFT also wants to know what URLs are allowed to display the typeface. Happily, it supports multiple entries, so be sure to add the name of your machine. For example, I added http://localhost:3000, so I could preview my work before showing it to the client.

NB: be sure to add all the URLs you’ll require, otherwise embedding will fail in Internet Explorer:

Incorrect font embedding sample seen in Internet Explorer

Here it is working in Internet Explorer version 7:

Font embedding sample seen in Internet Explorer 7

And here it is, with the “L”looking like ass, in Internet Explorer 6:

Font embedding sample seen in Internet Explorer 6

So why does it look like ass? Read on.


Well, there are lots of things that I haven’t explained about font embedding. One of the things is that it doesn’t always work well. When we converted the typeface to EOT format, we discovered that, for some strange reason, it wouldn’t show typographically-correct glyphs (like “”, —, etc.) in Internet Explorer 6. However, we were initially provided with a rip-off version of the original font. When we converted this to EOT, everything worked fine. Now why would this be?

Keep in mind that we’re now talking about different fonts. It turns out that font makers have the ability to declare embedding rights. It’s located in the fsType. It might be that when converting the font from TrueType to EOT, some of the characters of the font wouldn’t translate. This is guesswork & I might be entirely wrong.

Another problem, which I haven’t explained, is that accessing the boldface version of the font would make Safari crash. I thought that perhaps it was because I had declared the font in an incorrect way:

  @font-face {
    font-family: "VAG Rounded Thin Bold";
    font-style: normal;
    font-weight: bold;
    src: url('vag_rounded_thin_bold.ttf');

Do you see the problem here? I’ve declared the bold version to be bold—in other words, really, really bold—and initially thought that might have caused the crash. But when I changed the declaration to font-weight: 100;, the page would render—and then crash. We don’t have an answer to this problem & we’re still investigating the source of it. Once we’ve found out we’ll post the answer as an addendum to this article—but any suggestions from you would be most welcome.

So, that’s font embedding for you. A fairly mature declaration is hobbled in part by not having been used—the more usage it had, the more bug fixes we would have seen & the process would become more transparent. But at least this is a start.


Well, at least I know why Safari was crashing with the bold font now—and it doesn’t crash any longer. The solution is very obvious, actually—as things are always obvious once you’ve figured them out.

First, you declare the boldface version of the font:

  @font-face {
    font-family: "VAG Rounded LT Bold";
    font-style: normal;
    src: url('vag_rounded_thin_bold.ttf');

First of all, note that the font-weight is set to normal: you don’t want to make your bold font bold twice, as it then becomes very heavy. Now, in your stylesheet, style your strong (or, if you’re Old Skool, bold) with the font’s name, thus:

  strong { 
    font-family: "VAG Rounded LT Bold", "Verdana", sans-serif; 
    font-weight: normal;

You see that we set the font-weight again to normal: otherwise, the font becomes entirely too heavy. Voilà: complete!

And don’t forget to repeat this effort for your Internet Explorer users on your EOT files.

Update (27 April 2009): There’s an interesting article by Tal Leming about embedding web fonts from a type designer’s point of view. It’s an interesting read & Tal makes some very good points that are worth serious thought. The idea of a new type format with the option of specifying a domain in the root table is an attractive one, but he’s conscious about what this means for legacy fonts (i.e., the exclusive support of a new format would break sites using previously available fonts).

8 Responses to “Font embedding: A real-world example”

  1. Martin Hintzmann

    Martin Hintzmann Says:

    Have you found a solution to Safari, so it does not crash?
  2. Ray Drainville

    Ray Drainville Says:

    Dear Martin,

    In fact, I have, I just hadn’t updated the article—thanks for pushing me!

  3. Timur I. Alhimenkov

    Timur I. Alhimenkov Says:

    Wow! Thank you very much! I always wanted to write in my blog something like that. Can I take part of your post to my site? Of course, I will add backlink? Sincerely, Your Reader
  4. Ray Drainville

    Ray Drainville Says:


    Certainly, post away! I note your blog is in another language—I hope that translating this post won’t be too troublesome :)



  5. M. JabaDisa

    M. JabaDisa Says:

    Thanks, Ray! Really good to see font embedding in a spotlight, since it has always been an obstacle in web development. Will try it out and if I find something useful I’ll be sure to let you know :)

  6. Ray Drainville

    Ray Drainville Says:

    No problem & I’m so happy that you found the article useful!

  7. Philip

    Philip Says:


    Glad to finally find your post about this @font-face issue that keeps crashing Safari. I tried to implement your solution by declaring the bold-version of the font to use font-weight:normal (as well as font-style:normal—in the green snippet, you typed font-style, but in the explanation below, you mentioned font-weight…) but couldn’t quite get it to work yet. Before investigating further on my end, hope that perhaps you can help shed some light on this issue further:

    1) Is this crashing behavior pretty much due to the “bold”-ing of embedded-fonts? It does seem so because on the page that would crash, I would first see regular texts loaded while Safari seems to wait for something on rendering the bigger/bold fonts before crashing….

    2) You mention that one needs to redeclare strong or b to be font-weight:normal with the bolded-font…. If so, that means all bold fonts on the page/site would have to use this new bolded-font. So what’s the use of having “Verdana”, sans-serif in the declaration as they won’t be used—and even if somehow they are used, I guess perhaps because the new font can’t be downloaded, the Verdana, sans-serif now are all normal, non-bolded, wouldn’t the UI look quite inconsistent?

    Thanks much! Philip

  8. Ray Drainville

    Ray Drainville Says:

    Dear Philip,
    Sorry for not writing earlier—I was horrendously busy & then I came down with the Swine Flu.

    You noted that my proposed solution didn’t work. In fact, I belatedly noted this, too. Everything seemed to be going swimmingly for a while, and then the crashing issues I mentioned above started to reoccur.

    It appears that there’s a good solution for the issue, and it reflects some confusion over multiple weights in @font-face usage (including very much my own). Ilia Draznin has an example using multiple font weights. In a nutshell, this is what Ilia suggests. Assume that you’ve a typeface called “FontName” that has multiple weights:

     @font-face {
        font-family: FontName;
        src: url(FontName-Thin.otf);
        font-weight: 200;
     @font-face {
        font-family: FontName;
        src: url(FontName-Light.otf);
        font-weight: 300;
     @font-face {
        font-family: FontName;
        src: url(FontName-Regular.otf);
        font-weight: normal;
     @font-face {
        font-family: FontName;
        src: url(FontName-Bold.otf);
        font-weight: bold;
     h3, h4, h5, h6 {
        font-family: FontName;
        font-weight: normal;
     h3 { font-weight: bold; }
     h4 { font-weight: normal; }
     h5 { font-weight: 300; }
     h6 { font-weight: 200; }

    You see what’s going on here? We’re picking out different font weights (Thin for 200, Light for 300, Regular for normal & Bold for bold), then we apply them to specific instances: in this example, h3 will be bold, so it taps the Boldface version of the font. It highlights the problem of trying to tap into various font weights, which is what I was struggling with.

    The example doesn’t fully answer all my questions, however: why do we initially specify the font-weight as normal for h3 through h6? And how do you tap into fonts where various weights are built into one file (Verdana, for example)? Still, though, it inches closer to explaining what is going on.