Moving Forward with Industry-Supported Font Embedding on the Web

First, let me apologize for not posting anything for a while. I try never to “post just for the sake of posting”. I like to have real issues to raise, and hopefully spark some discussion. I assume anyone reading this blog is much more interested in that than in what I had for breakfast today.

For the past two or three weeks I’ve been very focused on trying to make progress on Font Embedding on the Web. This might seem like a small issue – but in fact it is one of the major blockers to achieving real readability on the Web.

It doesn’t matter if you have all the sophisticated layout and text composition support in the world; unless you have the right high-quality fonts to use with it, the result will always be pretty awful.

The paucity of high-quality screen-readable fonts in Web pages is a critical problem that has to be overcome before we can move forward.

We’re used to a huge choice of fonts that work well if we’re designing or creating print. It’s fairly easy to create fonts that work at the high resolution of print, or on the Web at large sizes for headings and so on – although even there you have to careful that the fonts will actually be available on the reader’s system, or else make the poor-quality choice of creating headings as graphics, which means they can’t scale.

Fonts-as-graphics is a quick and dirty workaround, and it goes against the whole spirit of what the Web is becoming; a standards-driven model much closer to the original concept of HTML and its forebears, XML and SGML. Internet Explorer 8 will use Web-standards rendering by default.

There are two main contenders to solve the problem of font embedding on the Web: Font Linking, and Embedded OpenType.

Embedded OpenType (EOT) was originally a proprietary Microsoft technology, first devised to allow fonts to travel with Word documents, and later revised to allow fonts to be embedded in web pages.

It was introduced in Internet Explorer in 1996. But Netscape, the main competing browser, went with another system using technology from Bitstream. Neither became a standard, and as a result EOT languished.

About a year ago I realized it was critical to solve “Fonts on the Web”, and brought together a “virtual team” inside Microsoft to make EOT an open Web standard. The standards proposal is currently with the W3C, the Web standards body.

In the meantime, competing browsers introduced support for Font Linking, which simply allows raw TrueType font files to be posted on servers and called by Web pages when they need them.

There are a number of problems with Font Linking. Not only does it make it very easy to pirate fonts (and piracy is already a huge issue for the font industry), but it is expressly forbidden in the End User License Agreement of just about every one (if not all) of the well-known, high-quality, commercial fonts. Not least of the problems is that no-one even thought of raising the question with the font industry before simply implementing it in Web browsers.

Font Linking proponents say that means people will use free fonts, and the font industry can adequately police piracy of commercial fonts. I disagree completely.

Policing font piracy is hard enough today. It’s only practical to address abuses by companies illegally using single-user font licenses as site licenses for all their computers. It’s just about impossible to police individual-user piracy. The Web would explode the number of instances, and any policing would be quickly overwhelmed.

Call me suspicious or paranoid, but I can’t help feeling that’s exactly what some of the more rabid members of the OpenSource community want – for font piracy to become as prevalent as music piracy. Intellectual Property should be abolished and everything should be free, as far as they’re concerned.

When we implemented EOT a long time ago, we held talks with the font industry and reached agreement on a system they could accept. One result of these discussions was that we actually revised the TrueType format (the tables of which are still at the heart of OpenType, no matter whether it contains TrueType font outline data or Adobe’s Type 1 or CFF). We created a set of “Embedding bits” which could be set by the font creator to disable embedding of that font, or enable different levels of embedding (read-only, editable, or full installable).

Earlier this month, font creator and vendor Ascender launched a new website called:

Ascender announced its support for EOT, and was highly critical of Font Linking. The site has lots of information, some free fonts, and a Web tool to make EOT font objects.

Adobe is already supporting EOT. Hopefully we’ll see other font vendors join the effort.

Even before I’d heard about the Ascender site, I’d decided to go and make some Web pages using EOT to show how fonts could make the Web much more readable.

I’m not a Web guru. I’m a type guy, and a writer. So instead of hand-coding HTML and CSS, I decided to use a publishing application, then embed the fonts after I’d created the pages.

One of the great things about EOT font embedding is that there is already a great set of really high-quality fonts out there which anyone who bought Windows Vista, Microsoft Office 2007, or Mac Office 2008 can already use.

We call them the C* fonts, since they were optimized for ClearType and we gave them all names which began with “C”. They all have Editable Embedding enabled, and they’re probably the best fonts in the world for reading on a screen. A lot of money and a huge amount of effort went into building them.

I designed my pages using three of them – Cambria for body text, and Candara and Calibri for headings, pull quotes, etc.

Given the current limitations of the Web, I made the pages fixed size. If you read my last posting, you’ll know I’m opposed to this – I want to see Adaptive Layout like that used by the New York Times Reader applied to Web pages. But we’re not there yet, so I had to compromise.

I took content from this blog to use in my experiment, so I didn’t have to write fresh stories as well as learn a whole load of new skills.

The pages can only be properly viewed in Internet Explorer, since it’s so far the only browser with EOT. But if you’re running another browser on Windows Vista, or you bought a copy of Office 2007 or Mac Office 2008, the fonts will already be on your system, and it should display OK. Otherwise you’ll get font substitution and the pages will break (big time!). They may even break anyway; for my first experiments I wasn’t concerned about cross-browser compatibility, oly about exercising font embedding…

With that caveat, you’ll find the pages at:

I created the font objects using WEFT, the Windows Embedding Fonts Tool, which you can find at:

Read the instructions and go through the tutorial before you try it for yourself, to avoid problems.

WEFT lets you create an EOT font object with a subset containing only the characters you use on your site, or which supports only the language in which you write. This reduces the size of the objects dramatically to give faster download times. That’s a huge plus, if you’re creating a Japanese website. A small subet would probably contain all the characters you’d ever use – and it would be well under a tenth of the size of the full font (Meiryo, for instance has some 22,000-odd characters).

The publishing application I used to generate the pages added a whole lot of its own proprietary code. My friend and colleague Chris Wilson took one look and freaked out.

Then he started to duplicate what I’d done using Web-standards markup, validated by the W3C’s HTML Validator service. You can find that at:

It freaked out even worse at my pages than Chris did. “85 coding errors, you moron! Starting with no DOCTYPE…”

I decided it was time I learned a lot more about Web standards myself – and about authoring pages using them.

So I bought a big stack of books and started to teach myself. And that’s also been occupying me for the past week or so.

I actually managed to write my first W3C-validated Web page (also using a stylesheet, no less).

One clear issue that I’ve come away with even this early in my learning: Authoring visually-interesting content by having to write HTML code using a text editor truly sucks!

I’m a type – and content – guy. I don’t really want to have to learn to become a coding geek. But I’m being forced into it.

It’s high time someone wrote an easy-to-use Web authoring tool which spits out clean Web-standards HTML and CSS, without adding a whole pile of its own (often proprietary) code.

Chris’ first attempt to duplicate my page worked really well – and it was less than 8K in size, when my original was nearly 40K.

Many of the folks I know seem quite happy coding in Notepad. But you really shouldn’t have to do that. There has to be a better way for the hundreds of millions of non-coders who also use the Web to create their own standards-compliant content.

I plan to talk to a number of different folks about that…


5 thoughts on “Moving Forward with Industry-Supported Font Embedding on the Web

  1. Andrew Savikas

    Bill,”Intellectual Property should be abolished and everything should be free, as far as they’re concerned.” That kind of hyperbole diminishes your argument, which does raise some important issues. The success of MP3s suggests that consumers strongly favor convenience over quality, above a certain minimum. I’m not convinced that the current Web is anything less than “good enough” for most people, especially as much of it migrates to mobile devices.

  2. Ben Weiner

    Hi Bill, a couple of small questions:WEFT lets you create an EOT font object with a subset containing only the characters you use on your site, or which supports only the language in which you write. This reduces the size of the objects dramatically to give faster download times.1. How do I add a comment to your EOT-font-styled page if some of the characters are ones you did not use when you generated the page, and which are therefore not in the downloaded font? Won’t text be less legible if some characters are rendered some in the EOT font glyphs and the rest in the browser’s default substitution font? How about if I want to write in Latin characters and include a quote in Greek or Japanese using the same, originally multi-script, font?2. Arial Unicode is 22MB. That will take a while to download. But Cambria, a complex C* font, is only 1MB, which is about a third the size of a 3-minute stereo MP3. Isn’t that still much larger than an average single-script (and single-weight) font file, which the majority of existing fonts are?Perhaps we don’t need to worry about subsetting too much?

  3. Bill Hill

    To answer your questions, Ben: If you live in a country with widespread broadband access and a set of languages (say, the Latins, Greek, Cyrillic etc covered by a font like Cambria) you don’t have to worry much about subsetting. But if that country happens to be Japan, China or Korea, your reader could end up having to download a 12Mb font to read the content on your site.Look at the statistics of Japanese. There are 22,000 or more characters in a font like Meiryo. But surveys have shown that 99% of all Japanese content can be covered by a subset of 2000 characters. An EOT font object could be less than one-tenth the size of the complete font, even if it had to include a handful of the less-commonly-used Kanji.Even in English or one of the other Latin-based languages like French, language-based subsetting will provide all the characters needed for anyone to write a comment.It’s good for site creators to have those kinds of choices available.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s