Monthly Archives: July 2008

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…


Adaptive Layout: Taking the Web beyond the "cave painting" stage…

There’s an interesting discussion going on right now at Smashing magazine’s website on the relative merits of Fixed Layout versus Flexible Layout on the Web.

It seems that designers are still battling to try to achieve the kind of control on the Web which they’ve always had when designing documents for paper. You know: the ability to place every piece of text and graphics exactly where they want it, to the nearest 1/1000th of an inch.

They’re still “living in Flatland”, desperately trying to hold onto the kinds of design approach that have worked great for the past 35,000 years or so, but are really holding back the Web from becoming all it can be.

Humans have been designing the display of information for about 35,000 years – the earliest cave paintings. For all that time, the First Law of Design has always been to ask the question: “What is the size of space I’m filling?” That applied whether you were painting on a cave wall, carving letters into Trajan’s column in Ancient Rome, or deciding to publish People magazine on pages 8 ½ x 11 inches in size.

Once the size of the area to be filled was fixed, then design could proceed.
Over a period of about 550 years, since mass printing first appeared, a Darwinian evolution took place. Lots of experiments were tried (and failed) until we settled on a size for body text that’s about 11 points, and a column width of between 55 and 65 characters, for material to be read at normal reading distance of about 50cm.

No-one scientifically planned it. What happened was that text quickly settled down at the sizes which were optimal for the human visual system. We read with an area of our retinas called the fovea, which is only 0.2mm in diameter. For more details on the psychology and physiology of reading, see some of the earlier archived articles in this blog.

Now, people often position their screen a little further away than they’d hold a piece of paper. So they should be able to adjust the text to a size that’s comfortable for them. It won’t need to change much – perhaps only a point or two in size – unless they’re reading on their living-room TV from ten feet away.

What many designers would like to do is create the same kinds of Fixed Layout they’ve been able to use in print. Their argument is, the reader can then use Zoom in his or her browser to scale those layouts to the size of their own screen.

They just don’t get it. They’re “Flat Earthers”, trying desperately to hold on to a world view that no longer makes sense.

There’s a new First Law of Design: “When creating content for the Web, you have no clue what size of screen the reader will be using”.

The range of possibilities is huge, from cellphone to laptop to desktop to living-room TV to cinema-sized screen.

At this point, any designer reading this page is probably throwing up their hands in horror and screaming “I can’t create one design that works for all of these scenarios!”

And that’s exactly my point. You can’t. Not with the Fixed Layout approach of the past. We need a new and robust Adaptive Layout technology to take Web design forward.

The good news is that the human visual system hasn’t changed, and many of the parameters we know from past experience still work. They just need to be used in a much more flexible way.

A key concept behind Adaptive Layout is that information on the Web has to become just like water. Water doesn’t just flow; it also takes the shape of the container into which it’s poured. In other words, it should adapt to the screen on which it’s being read.

The starting point should always be the human who’s actually reading the content.

Let me try to describe my ideal scenario, and then see how it fits into an Adaptive Layout world.

First, there’s a big difference between browsing for content, and then focusing on a piece of content in order to read it.

When I’m browsing, I want easy access to all the tools of the browser – menus, buttons, toolbars etc. But when I’m reading, everything on the screen which isn’t content is just a distraction and a waste of space. I want it to all go away.

When I’ve browsed to a piece of content I want to read, I should be able to hit a “Reading” button, and only content, and perhaps some basic navigation buttons like “Next page”, “Previous page”, and a button to get me back to Browsing mode, should be visible. The F11 shortcut on Internet Explorer, for example, makes the browser go full-screen. It’s not discoverable enough today, and not effectively used by any sites I know of, but the capability’s there.

Next page, Previous page? Well, yes, the content should be paginated. Research has shown consistently that paging is much better for reading than scrolling.

What should a “page” look like? It should look like the full size of whatever screen I’m using. If the browser knows the text size the reader wants to use, then it knows the width of a column. If it knows the size of the display, then it can calculate how many columns to display.

If you then throw in all the typographic techniques we’ve learned over 550 years like kerning, ligatures, great word- and letter-spacing, etc. you get text that’s as readable as text on paper. Since you know how many columns are in use, you have a grid for placement of graphics.

To see this kind of layout at work, take a look at the New York Times Reader, or the Seattle P-I Reader. They were both created using the proprietary Windows Presentation Foundation technology. But the same thing can be done on the Web, using Web-standard content.

Instead of trying to hold on to the past, the design community and software developers should be working together to develop this technology and make it mainstream for the Web.

It took hundreds of years to develop the state of the art in readable text on paper. We’ve been creating and reading Web content for less than 20 years. We’re still at the “caveman painting on a wall” stage as far as creating content which can be read on the whole range of screens is concerned.