Adobe, Web fonts and EOT
Adobe is strongly supportive of the effort to make Microsoft’s EOT web font format an open standard. Indeed, Adobe pays for Steve Zilles’ time, and he will be chairing the EOT standardization effort, should the W3C accept the proposal in principle. We will be updating our licensing FAQ to make it clear that our existing font license terms allow EOT usage, and do not allow linking to original fonts placed on web servers.
Why do we support EOT? Our surveys of web designers and font developers have made it clear to us that users want an HTML/CSS font solution that allows them to use any font they want, and most of them would like to do so legally. In particular, they want to be able to use regular retail and OS-bundled fonts. With original fonts on web servers, hardly any retail or commonly-used fonts could legally be used; only freeware and open source fonts, some shareware, and a handful of retail fonts.
Some open source advocates argue that there are enough and good enough free/libre and open source fonts available that retail/commercial fonts are unnecessary. Whether they are right in principle or not (and I think not, given how few such fonts are decently made and come in even a basic set of four styles with bold, italic and bold italic), it doesn’t matter: the web designers who make web sites want to be able to use a vastly wider variety of fonts, and companies and organizations that have a web presence want to use their existing visual identity online, or at least a close adaptation. Being able to use 50% of the world’s fonts instead of 5% comes a lot closer to meeting these needs.
Why is it so? EOT comes vastly closer because many more type foundries and type designers are comfortable with EOT than are comfortable with original fonts on Web servers. And that includes Adobe.
One aspect of EOT is often misunderstood. As an open standard, EOT is not a DRM format in the usual sense. Yes, back when Microsoft had a proprietary and secret specification, EOT was a DRM font format. But as an open specification, anyone who wants to program the tools to do so will be able to create or convert fonts to and from the EOT format. What it does instead is give us a format that is not directly usable in common operating systems. If an end user wants to take an EOT file and convert it, there won’t be anything physically stopping them. But it will be difficult for them to be unaware that what they’re doing is usually wrong and illegal (dependent on the copyright and licensing status of the font in question).
As far as protection of the fonts (something type designers and font vendors care about), the situation is not that much different from fonts embedded in PDF or SWF (Flash) files. The fonts are there, the specs are public, and in principle somebody can rip off the font. Doubtless a few people will. But I honestly expect the same thing will happen with EOT as with these other formats: even a mild barrier is enough to keep most people honest. Think of it as equivalent to a traffic signal: most people will stop at the red light. That’s good enough for us, and for many other font designers/vendors as well, it seems.
Another way in which EOT is not a DRM format is that it is not the sole or even the primary format an end user can license. Although some font vendors may see an interesting opportunity to license fonts directly in the EOT format, customized for each user and web site, I don’t see this possibility as eliminating sale of licenses for “regular” fonts. Certainly at Adobe we intend to continue to license OpenType CFF fonts, from which users can then derive EOT fonts for their HTML/CSS projects, just as they do various embedding operations with those fonts.
If you’re a web designer wanting to use fonts in HTML/CSS, let’s compare this to the music DRM situation. This is not like you buying a protected music file that you can’t move to another machine and can’t copy freely. This is instead like providing an interchange format for your music files that gives you a new option for letting your friends listen to about half your music files legally and legitimately… while you still have the original unprotected file as well! Sweet! It doesn’t stop you from copying your original files and giving those to your friends (likely illegally), but it does give you an additional option that lets you share your music. (I can already hear some of you saying, “okay–and this is a bad thing why? Which is of course exactly my point.)
So that’s why calling EOT a DRM format as a pejorative or as a scare tactic is misleading at best: it implies a bunch of things that are not true of EOT, at least not any more.
* * * * *
On August 28th, an absurd post went up on Slashdot, which is in many ways typical of the kind of FUD going around about EOT. Here are my comments on that piece:
– There is no requirement to subset in EOT, and hence no requirement to regenerate EOT files when a page changes. However, subsetting may be a good idea for download size reasons! The availability of subsetting as an option is an advantage of EOT over unprocessed original font files. Microsoft’s existing WEFT implementation may subset by default, but users can override that as they wish, or customize the subsetting (hmm, not going to need all that Greek and Cyrillic support on my web page!). Of course, if the font license allows, one could do subsetting of native fonts as well, but that has complications because of the fact that you’re spinning off incompatible fonts into the wild. Keeping web fonts separated from general-use fonts is a Good Idea if you want to have the option of subsetting.
– Although the original incarnation of EOT required the EOT font be tied to some particular URL/domain, the spec submitted to the W3C specifically removes this requirement. EOT fonts which omit this informationa are still compatible with Microsoft’s existing EOT support.
– The primary reason EOT has been “largely ignored” is because it was a Microsoft-only “standard”; making it an open spec avoids this problem. Nothing to do with subsetting.
– Having a public spec (already available now) EOT is no longer a DRM format in the traditional sense, as described earlier.
– EOT can do a much better job of “breaking Microsoft’s forgotten monopoly” (on web fonts) than original font files; many times more fonts are or will be legally usable with EOT than as OS-native fonts on web servers.
My previous web font posts on web fonts and EOT:
– First comments on the Web fonts problem (March 2006)
– Comments on original fonts vs EOT format for Web fonts, and survey (November 2007)
– Initial results of my end user survey (November 2007)
7 Responses
Comments are closed.
Thanks for the summary!About the URL binding:You’re saying, one can build an EOT font that works on every website and this font will work in every version of Internet Explorer with EOT support?[Yes, that’s my understanding, from talking to folks at Microsoft. – T]
Why should font files deserve any special “protection” over HTML, CSS, JPEG or SVG? Do you support EOT style format for “protecting” other files but fonts, too?[These other formats are not system resources that you install at the OS level and get some intrinsic benefit out of, so the analogy is weak. But this is a practical question, not a moral one: Web authors want to use fonts, and the folks who own the rights to the fonts are largely unwilling to have them placed in their original form on a web server, so how do we reconcile these conflicting needs? It’s not a question of what “font files deserve” but of what needs to be done to enable web authors to use a vastly wider range of fonts, and folks reading web pages to see what the web authors intend. – T]
I can’t wait to use and see more fonts on the internet! Finally!(This sort of reminds me of font-embedding in PDF files. Had Adobe not won the lawsuit “Adobe vs ITC” it would have ben illegal to embed a font in a PDF.)[I’m excited about it too. On the side, I believe you’re thinking of “Agfa Monotype v Adobe,” and as far as I can tell, the opposite outcome would *not* have made it “illegal to embed a font in a PDF.” – T]
This is a great post. I for one can’t wait until the various browsers implement font embedding in some form – and EOT in particular. This is the only practical option on anyone’s radar, and it’s been a long time coming. Kudos to the practically minded people at MS, Mozilla and Adobe for seeing this for what it is, an opportunity to finally move forward with embedded font technology on the web.Now we just need something more useful than WEFT – which the last time I tried doesn’t actually play nice with OpenType CFF fonts (.otf). The generated font’s don’t render properly in IE – something to do with clear type I think. Hopefully the open spec will help lead to a tool that actually works (a tiny hurdle to be sure).I can’t wait, thanks. 🙂
Okay, not *illigal* but you required the origional font to view the PDF correctly. (Correct me if I’m wrong).[You’re wrong, or confused, anyway. You’re describing a situation in which the font is not embedded in the first place. – T]That’s just not an option for my clients. By allowing designers to enclose font-info inside the PDF Adobe just made is much more practicle. Isn’t it the same thing we see happening now with webfonts? A technique to allow the font-owners to embed font-info?[Essentially, yes. The primary difference is that the font is not literally embedded, but linked. But the net effect is the same: seeing the document in the fonts used by the person who designed the document. – T]
the images in webpages are linking with src=”path/to/img.file” resource in the html code, and users can save images easily with a ‘save image as’ menu, and get the .jpg, .gif or .png in their local directoriesthese images have a license usually mentioned on the same website, and the users must respect that licenceif the license is not specified in any side, ‘all rigths reserved’ by default according global agreements on intellectual propertyif things are so with images files,why the fonts files is diferent?why not src=”path/to/font.ttf” ??thanks!saludos![95% of the fonts out there – and >95% of the ones web designers want to use – are font software that is licensed from retail font vendors. Said font vendors don’t want to let folks just place the fonts unprotected on web servers, so their licenses won’t allow it. End of story there. Unlike images, the average web designer is not capable of making a useful font, and a useful text font takes weeks, months, or years. – T]
One thing which I have disliked in the past about eot is how easy this made it for people to produce webpages in totally non-standard encodings (e.g. mapping Bengali to Latin) instead of employing Unicode. Any chance the open standard could have something in it to avoid encouraging that?[This is a problem with linking to regular desktop fonts on web servers as well; it’s not specific to EOT. As soon as the designer can control what font is used/referenced reliably, they can use a non-standard encoding. Not much to be done about that, but it’s a small price to pay, in my mind. It also means they can make reliable use of Unicode PUA characters for glyphs which have no “real” Unicode encoding. In fact, they have much the same advantages and limitations of folks working in print…. – T]