Archives filed under "eot"

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:

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

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 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:

Here it is working in Internet Explorer version 7:

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

So why does it look like ass? Read on.

Caveats

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 free 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.

Update

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).