The history of a model for fonts on the Web


Bert Bos | History of WebFonts

Bert Bos (W3C)
SXSW conference
Austin, TX, USA
March 13, 2010

1994–1996: before WebFonts

< Oct 1994:
User style sheets

Oct 1994:
Author-reader balance
→ font problem

font download?
font synthesis?
most similar?

In 1994, I was working on a browser (optimized to integrate the kind of information sources that scholars in the humanities use). It handled a subset of SGML, including HTML, and it had style sheets. The style sheets had many features that are still in CSS, and, of course, it specified fonts. But there was no particular difficulty with that, because the style sheets were strictly for use by the reader. A reader presumably wouldn't specify a font he didn't actually have.

Then in October 1994, Håkon Lie posted his proposal for style sheets. There were two or three others than ours, but his caught my eye in particular for one feature: it postulated a (yet to be specified) algorithm to balance the author's desired style against the reader's.

We combined our ideas and the result was Cascading Style Sheets. In syntax it doesn't resemble either of our two style sheet languages, but most of the features are still there. But now we had a problem with fonts…

If you negotiate, say, the author's request for red text and the reader's preference for blue text, you may end up with red, blue, or even something in between, but it is still a color and technically you can draw it. (The aesthetics is another matter…)

But if you combine the reader's choice of font A with the authors preference for B, and the algorithm yields B, it may well be that font B isn't actually available. We considered several solutions, but most of them could be dismissed immediately.

We thought about downloading (embedding) the font, but (1) fonts are big and even on the academic networks of the time you wouldn't want to wait for a font to download; and (2) there was no common font format.

We thought about font synthesis as well: pass something like a PANOSE number and create a font with those characteristics on the fly. But such a font is likely to be so ugly that both author and reader would prefer some other font instead.

We thought about finding the most similar font, again based on something like PANOSE numbers, but that would probably also lead to a font that neither author nor reader would have chosen.

And in any case, we couldn't make the style sheet language too complicated, because it had yet to be adopted…

And so we settled on a solution in two parts:

  1. The concept of a font set, i.e., the author can specify a list of fonts in order of preference in the hope that one of them at least is available on the reader's machine.
  2. Five generic font family names (serif, sans-serif, monospace…) so that an author could specify that, if none of his fonts was available, he at least wanted a serif font.

That became a standard (W3C Recommendation) as CSS level 1, in 1996.

1997–1998: WebFonts!

April 1996
First Fonts WG

font metrics

download & (virtual) embedding
any format
type-1, truetype, eot…

While CSS level 1 was going through its final reviews, in 1996, we started working on CSS level 2. CSS was well received and we thought we could add a number of features that we wanted, but that had been too advanced for level 1, including font download.

We created a working group, the first incarnation of the Fonts Working group, and asked Adobe to explain what they had done for PDF. With their help, but also Bitstream, Microsoft and others, we created WebFonts, also known as the '@font-face' rule of CSS.

The group's results were integrated into CSS level 2 and allowed not only font download, but also synthesis of a font with the same metrics (primarily meant to bridge the time while waiting for the font to download).

There still wasn't a clear clear common font format for all platforms. So we didn't recommend a single format, but provided an open-ended list that included, among others, Type-1, OpenType and EOT.

CSS level2 became a standard in 1998, and then we waited to see what would happen.

Microsoft implemented the download feature straightaway, using their own EOT format. Which made sense, because EOT seemed to have tackled the copyright problem. (Of the handful of free fonts that existed at the time very few were any good.)

In the context of the browser wars that raged at the time, Netscape decided to implement something completely different. They used a technology from Bitstream called PFR (Portable Font Resource) to try and offer similar capabilities, but without using the WebFonts framework. The result wasn't very good and distributing commercial fonts as PFR was probably illegal in many countries, too. Now, in 2010, PFR as such still exists, but it is no longer supported on the Web.

And for a long time, nothing else happened…

2006–2008: need for a format

2006: Image Replacement Techn.
CSS WG decides to act

Simplify WebFonts?
Enhance 'content' prop.?
Standardize font format?

OpenType in zip file?

2008: Microsoft & Monotype submit EOT
Turns out to be easy to implement…

EOT, the only format available with WebFonts in practice, was in use in some parts of the world, especially for languages for which there were few fonts available, but it couldn't be called a big success. Designers rarely used it and no other browsers than Microsoft's Internet Explorer had implemented it.

Then, at one of its meetings in 2006, the CSS working group discussed a phenomenon that was clearly on the rise on the Web: image replacement techniques.

When CSS was started in 1994, the reason wasn't just to make Web documents more beautiful, it was also to provide an alternative for practices that went against our goal of a semantic Web: <FONT> tags, images instead of text, spacer elements, etc. We wanted HTML documents to be accessible, device-independent, easy to maintain, and re-usable, and so we tried to make the separation of text/structure from style as easy and attractive as possible.

The image replacement techniques were not quite as bad as the original practise of putting an image in an HTML document. In their case the text was still in the document and the images only in the style sheet, but they still led to accessibility problems and documents that were hard to maintain. E.g., you cannot cut and paste text when the text is replaced by an image.

We, the CSS working group, decided that the designers were clearly demanding better font support. We could improve some small things in CSS here and there, but the main job seemed to be to get WebFonts (the '@font-face') adopted. We decided to enhance the 'content' property and simplify WebFonts by removing the font synthesis part, and we discussed formats: what formats would lead to the most supply?

W3C now had a graphics format, SVG, that included a way to define fonts. We expected (and it seems we were right) that SVG would eventually come to be integrated with Web documents. But SVG fonts were not a sufficient answer. They lack advanced features that you find in OpenType, e.g. And they don't solve the problem of commercial fonts, which you cannot just put on the Web for everybody to copy.

Because, although by now the number of free fonts had increased, it seemed designers wanted to use commercial fonts, such as the ones that come with Adobe Illustrator.

EOT promised to solve that problem. It had apparently both the full power of OpenType and a solution for distributing a font without losing the information about its license. Independently of each other, both Håkon Lie and I challenged Microsoft to open up the format and show how it could solve our WebFonts problem.

They did. The person who made it all happen was Paul Nelson, one of Microsoft's representatives in the CSS WG at the time. He got the right people to sign off on the submission of EOT to W3C, and he found and cleaned-up the EOT documentation. But from the speed with which he got the approval I suspect Microsoft had already started thinking about opening EOT before we asked.

Paul even managed to convince Monotype to join W3C and submit their patented compression algorithm MicroType Express, which is used in EOT. Submitting a technology to W3C implies that it becomes Royalty Free if it becomes a W3C standard.

There is some administrative work involved in preparing a document in the right format for publication as a W3C submission, but in March 2008 EOT and MicroType Express were published as a joint submission by Microsoft and Monotype.

Based on what EOT was supposed to do, I had imagined what it would look like on the inside. But I was afraid that it wouldn't be like that at all, because experience shows that document formats that come out of Microsoft aren't always as elegantly designed as one might wish. But it turned out to be everything I had hoped for.

EOT is simple and straightforward. It has one or two things that are redundant, but not harmful, and easily removed. It has a tiny bias towards Windows, but also nothing that can be fixed easily.

To prove to myself that it is indeed as easy to write software for as I thought, I recently did just that. It took me just one day to write a program to read and another to write EOT files. On a Friday night I wrote eotinfo, to decode an EOT header and display its contents in a readable way; and on the Saturday I wrote mkeot, which creates and EOT file. And so far they work perfectly.

So, in March 2008 I thought we were nearly done. EOT didn't need much work to be made into a proper W3C Recommendation. We just needed to check that the font industry was indeed willing to use EOT, as Microsoft believed. There were indications that that was indeed the case.

2008: talks w/ font industry

What do designers want?

What does the font industry want?
W3C talks to many people

A few want DRM…
…but as long as EOT becomes a standard they will accept that, too

During the summer and autumn of 2008, I talked to many people in the font industry: font makers, font vendors, makers of font software, and designers. I met big companies (Monotype/Linotype, Adobe) but also small and tiny little companies. And some of my colleagues at W3C did the same.

The conclusion was that there was a range of preferences: from people who wanted EOT to people who would rather have something with DRM, but who were at the same time realistic enough to see that DRM is not in the current zeitgeist and were willing to accept EOT, once it was a standard.

What made EOT acceptable, even though it does nothing to make copying difficult, is that it at least makes doing the right thing easy. Anybody who wants to redistribute a font that comes as an EOT can easily see what the license is. The core of the license is even machine-readable, so you don't have to know English.

In other words, by the end of 2008, things looked good. And I already calculated: six month to rewrite the EOT specification, fix the ambiguities, and add the conformance requirements; six month more to create a test suite, make the first implementations and test them, and by the end of 2009 we would have a standard for font embedding on the Web and our old WebFonts would finally come into its own.

I was wrong.

2009: talks w/ browsers

Opposition from browser makers

Compression costly
Usability of EOT vs raw OpenType…

DMCA in the US
Can you exclude that somebody considers EOT to be DRM?

I hadn't thought the other browser makers, in particular Opera, Mozilla and Apple, could be opposed to EOT. They were already showing interest in WebFonts and EOT looked easy enough to implement. We could talk about dropping some optional parts, such as the compression, but those were details, weren't they?

In reality, when W3C proposed to resurrect the Fonts Working Group in order to standardize the next version of EOT, the three browser makers protested violently.

There were arguments about the usefulness of the special compression. Was it worth adding new code to the browser for a compression that was better, but not an order of magnitude better than the compression that the Web already used, viz., gzip?

There were arguments about usability: even though authors are used to adapting all resources for the Web (from Word to HTML, from TIFF to PNG, from 10 megapixels to less than 1, etc.) if they could just use TrueType and OpenType, instead of EOT, that would avoid one step.

But the argument that wouldn't go away after discussions was the DMCA. The DMCA is a law in the US that is meant to better protect copyrighted works and one of the things it does is to make it a crime to circumvent an effective technical measure that is designed to make copying difficult. In other words, circumventing DRM.

The scenario is as follows: imagine somebody implements EOT according to the standard. That means that the software looks in the EOT header for one or more URLs and does a string comparison of those URLs against the URLs of document it is about to render. If one of the URLs matches, the font can be used, otherwise not. Parsing the EOT header is a few dozen lines of code and the comparison itself is two lines.

Now imagine somebody else takes that software and removes the two lines that compare URLs. The result is a program that applies fonts in all cases, against the standard and, in some cases, against the licence of the font.

If you can find a judge who is willing to claim that those two lines constitute an effective DRM and that removing them is tantamount to circumventing it, then you can claim that the author of the original software is an accomplice, because he provided most of the code.

It's an unlikely scenario, but it is apparently enough to stop any attempt to protect copyright as long as the DMCA exist. Software makers simply do not want copyright information that can be read by software. Because when it cannot be read, you cannot be liable for not reading it.

2010: WOFF

Need a format that:

contains all of OpenType
(even future versions)
but is not OpenType

no license info
requires little code
not much less efficient than EOT

There were ideas for an “EOT light,” a version of EOT without license information, with the idea that the fact that it was a special Web font and not normal OpenType would at least tell people that the font wasn't meant to be copied and installed locally. But using EOT for that was also confusing, given that existing software already offered more features.

So we settled on a new format, called WOFF, that was proposed by Mozilla. Just like EOT, it contains a full OpenType file and thus keeps all the advanced typographic features, but the OpenType file is embedded in the WOFF file differently than in an EOT file, and the file is always compressed with gzip.

W3C now proposes that the new Fonts Working Group makes a standard from WOFF. At this moment, March 13, 2010, the official review period is over since a few hours, but the results aren't known yet. They are expected around April 1.

I'm still optimistic and so I already invite all of you to join the effort, starting in April. If you're a company, you can join W3C and become a member of the working group. We'll need people to help with editing and testing. You can also join the public mailing list <> and help us develop the specification and promote the result. Joining the public list is open to everybody and implies no special commitments.

2011-…: WebFonts for real?

A new Fonts WG is under review

We should know more by April

The end