… until September 2008.
W3C is investigating if it should set up a WG to make a standard version of EOT. There is no standard for embedding fonts in Web documents yet, but EOT, with some improvements, could become one. Microsoft and Monotype submitted their technology to W3C for that purpose. W3C staff asked many companies and people for their opinions. This is a summary.
The first W3C Recommendation for CSS level 2 (1998) included a feature called “Web Fonts” to deal with the situation where a style sheet referred to a font that wasn't present on the user's machine. One thing it allowed was a link to a remote font file so that it could be downloaded. Only Microsoft decided to implement it.
The Netscape 4 browser added similar capability, using TrueDoc PFR technology from Bitstream, but as a proprietary extension to HTML rather than through CSS. The extension was controversial, because it didn't restrict itself to fonts that were embeddable. At the moment, there are no browsers that support PFR.
More recently, SVG adopted the CSS properties and it is thus possible to link to fonts from SVG, without going through CSS. There are also plans to include the same properties in XSL2.
The reason Web Fonts didn't become popular is no doubt that implementing it wasn't worthwhile at the time. There weren't any fonts to download.
The reason that Microsoft could implement it was that they saw that font embedding is just a special case of font linking. An embedded font has a two-way binding: document to font and font to document, while a linked font has a one-way binding: document to font. Microsoft thus made EOT (Embedded OpenType) to add the two-way binding that OpenType by itself didn't provide. But they kept it proprietary.
Creating a format separate from OpenType had the added advantage that an embedded font resource was easily distinguishable from an original font, by its file extension and by the contents not looking like OpenType.
This situation lasted for about eight years. Then, in 2006, Håkon Wium Lie started a campaign for Web Fonts and in 2007 the CSS working group raised the priority of the CSS module for fonts.
The group had discussed that before, because of the increasing popularity of image-replacement techniques, where designers replace a heading with an image (using some CSS properties) in order to get exactly the fonts they want.
Håkon also convinced YesLogic (in 2007) and Apple (in 2008) to implement font linking (without embedding), in Prince and Safari, respectively.
Around the same time, Microsoft decided to offer EOT to the other implementers. With the help of Monotype (owner of part of the technology), they submitted it to W3C at the end of 2007.
Then the discussion really started, at first with the arguments that we expected: EOT is DRM and therefore evil, font linking makes people steal fonts without knowing it, etc. It seemed a matter of bringing the experts together and finding a consensus, like W3C has so often done in the past. Unfortunately, the positions only seem to have moved further apart in the past months.
Let's look at the arguments.
The argument was put forward that the best way to share a font is to share just its URL. EOT as described in the submission only deals with embedded fonts, i.e., each document or group of documents needs its own font resource that's bound to those documents. But when the license of the font allows it, it would be good to have just one EOT file that is linked from everywhere.
In fact, Microsoft's implementation already supports this and it should be easy to add it to the specification.
EOT makes it convenient to subset and compress a font without confusing the subsetted version with the original. This should be available also for “free” fonts, those that can be linked instead of embedded. The argument is basically the same as the previous one: it should be possible to use EOT with an empty set of bindings.
Some implementers expressed fear that EOT would require a browser to check the URLs in a font resource not just to be conforming to the specification, but because of a legal obligation.
It's certainly an aspect to discuss, but, according to some lawyers, the risk isn't serious enough to hold off the start of a working group.
The discussion is not unique to fonts. As more and more metadata of online resources becomes machine-readable, the question will be asked more often if the fact that data is machine-readable implies that machines must read it.
Another critique of EOT was that EOT makes the machine-readable license data easy to reach, but hides the human-readable one. There is also no standard way to include a URL, the license is just plain text.
If this is accepted as a requirement, it seems adding a URL to the EOT format would not be very difficult.
EOT has at least one limitation that makes certain fonts not suitable for embedding in EOT: EOT appears to limit font families to have no more than four variants.
OpenType supports larger font families. It seems not difficult to extend EOT to use the same mechanism as OpenType.
EOT is specific to OpenType. OpenType is widely supported, but in the future there may be new font formats.
The working group should certainly discuss if EOT should be extensible. Without further discussion it is not clear what the requirements are.
If you have a free font you could just upload it and point CSS at it. EOT would require converting (wrapping) the font first, which seems an unnecessary step.
However, if the font is to be subsetted, a conversion is necessary anyway. And if a document refers to a mixture of free and non-free fonts, it may also be easier to apply just one procedure to all of them.
Still, it's an argument for allowing both raw font formats and EOT on the Web.
It has been suggested that a Web server could check the “Referer” header of HTTP and only serve fonts if the header indicated a permitted document. It's a solution that some sites use to prohibit “deep linking” but most people recognize that it doesn't work very well.
Some organizations in fact recommend to users to turn “Referer” off for privacy reasons.
Another idea, put forward by Mozilla, is to let a browser check the links from a font to a document, like in EOT, but without creating a new font resource. Instead, those URLs would be passed alongside the font in an HTTP header.
For ease of use, HTTP headers would not be needed on a font that was valid for all documents on the same server as the font itself. Free fonts, on the other hand, would need an explicit header to say they are not bound to a single domain.
W3C has a working group charged with creating HTTP headers to deal with certain security issues in JavaScript. That working group could extend its scope to licensing issues as well.
The association between the font and the document is clearly less strong than with EOT: downloading the font resource or moving it to a different server removes the metadata. Very few people have so far given their opinion on this idea.
Some people asked for a system where fonts would be embedded without having to make copies. Instead, the font would stay on the font vendor's machine and only a digital key would be passed around. Whoever has a valid key for a given domain or document can use the font.
This doesn't allow for subsetting or offline viewing. But more importantly, there are no proposals of concrete technology.
There are thousands of fonts for the Latin script (some limited just to ASCII or even just uppercase ASCII), but the situation is different for some scripts in the middle and far east. There is often no market for fonts there and there are just barely some free fonts to make displaying Web pages possible at all. Myanmar is an extreme, where there are probably just three fonts available that are compatible with Unicode version 5.1.
An interoperable font linking solution is essential for such scripts. Whether it is EOT or something else is only a secondary consideration.
Microsoft's Silverlight version 1 doesn't use EOT and creates unprotected, downloadable OpenType files. Microsoft's competitors naturally claimed unfair competition: If W3C standardized EOT, DHTML/AJAX applications might have to use EOT, but Microsoft itself uses an easier solution.
Microsoft has since said that they made a mistake and promised that version 2 will not create raw font files anymore, only embedded ones. So this argument is no longer relevant.
Apple holds two patents related to “hinting” (US patents 5155805 and 5159668) and if they affect OpenType, as Apple claims, then they indirectly affect EOT as well. The W3C Recommendation would only describe EOT, not OpenType, and thus W3C's policy for Royalty Free patents does not extend to OpenType.
The patents can be worked around and haven't stopped OpenType from becoming the common font format even for Open Source software. Moreover, the patents expire in October 2009.
This argument is against OpenType as such, not against EOT in particular. In practice, very few people appear to be against using OpenType.
What's called DRM is often just anti-copy schemes that try to make it difficult to copy, rather than tell when and where copying is allowed.
For that reason, people at Creative Commons have started using a new term, DRE (Digital Rights Expression) for the machine-readable expression of who owns what rights. Another name suggested for the type of metadata EOT provides is “domain locking.”
Many people classify EOT as DRM and see it as another scheme to take away their freedom. More thoughtful arguments point to the fact that several unfortunate laws, such as the DMCA, now refer to DRM and stifle innovation and freedom even where the DRM technology itself would be relatively harmless.
EOT, now that its specification is public, is in fact a DRE: it's almost as easy to falsify the license in an EOT file as in an HTML page. EOT (and OpenType/TrueType before it) allows font designers to put a license on a font in the same way HTML authors put a Creative Commons license on an HTML page.
Mozilla has stated that they don't want EOT. But they are not opposed to letting the browser check the license, as evidenced by the proposal to let HTTP headers carry license data.
Microsoft has said that it is impossible for them to support linking to native OpenType as long as font vendors oppose it.
Apple's Safari has implemented font download with no checking of licenses. They said they are against EOT, but would not be against browsers checking licenses, e.g., using Mozilla's proposal.
Opera remarked that there are more existing and announced implementations for downloading native OpenType than for EOT. They conclude that the market apparently doesn't need EOT and thus they see no need to support it themselves either. W3C's limited resources should be spend on more important standards.
(Of course, the problem of limited resources goes away if one or more interested companies join W3C and send delegates to help develop EOT.)
Several font vendors and type designers expressed opinions very similar to one another: They are in favor of standardizing EOT, believe it will cause more fonts to be created and sold, and believe it protects sufficiently against casual font misuse. EOT is comparable to PDF in that respect. They sell fonts that are embeddable, but not installable. Companies with opinions similar to this include Monotype, Adobe, Ascender, Dalton Maag, Hoefler & Frere-Jones, and Bitstream.
Many recognize, however, that people also want to use the available free fonts without embedding them and that browsers will thus download raw OpenType files as well, hopefully with some precautions.
The makers of FontLab are also supportive of EOT standardization, and believe that fonts on the Web and fonts on the desktop are different things and better kept separate. (An opinion also expressed by Stephen Coles of FontFont/FontShop/Typographica.) But as a tool maker they are flexible to support whatever solution is chosen.
Web designer Chris Andreola (adcSTUDIO) is also a supporter of EOT, but stresses especially that Web Fonts must be easy to use, otherwise they won't be used, even if they provide higher quality. A thought shared by Ivo Gabrowitsch (FontShop/FontFont).
Adam Twardoch of FontLab explained why, in the view of many people in the font industry, fonts are not like MP3s. Fonts should be compared rather to the master tapes, while an MP3 is more like a document that uses the font. The document uses a particular font just like an MP3 uses a particular instrument. Consider a radio station that plays just one song all day long and compare that to a site that uses just one font on all pages. The former is not acceptable to people, the latter is normal.
David Crossland, a type design student and supporter of free software, is afraid that EOT, even though it is more metadata than an anti-copy mechanism, will still fall under laws of the type of the DMCA in the US and thus become a barrier to innovation.
David Berlow (The Font Bureau) is of the opposite opinion. He thinks EOT, especially now it's published, doesn't give enough protection. He rather wants a solution where checking licenses is done by (the servers of) the font vendors themselves.
Some people mentioned that it would be good if browsers and other tools exposed some of the metadata more clearly. Many browsers already have ways to a list of links and images. It would be nice if they showed not just the list of links, but also who is the author of each. A set of standard icons similar to Creative Commons icons to flag the major types of font licenses could help authors recognize them.
Arabetics's founder Saad Abulhab repeated the concern that the first priority was to have an interoperable font download solution at all, because for several languages it is currently impossible to make Web pages at all. (Hrant Papazian of The Microfoundry expressed the same concern.)
He also mentioned an advantage of EOT: it allows people to see fonts before they buy them, by means of a read-only document with the fonts embedded.
Hrant Papazian said that it was important that fonts on the Web allowed all the features of OpenType, including, e.g., bitmaps and hinting. (EOT, of course, allows that.)
Some font vendors suggested that there might even be a market in Web services where people can have an EOT font made for them online, instead of making it themselves with a tool like WEFT. They will have the latest versions and possibly more sophisticated subsetting then with WEFT, leading to smaller files.
Created 5–10 September 2008. Last updated $Date: 2009/10/23 17:40:36 $ GMT