The Two Central Questions Confronting EOT Web Fonts

There's a big debate happening about EOT vs. TTF fonts for the web. I see there being two central questions:
  1. If EOT was the right approach, why haven't we seen any deployment by users, developers, or font vendors, even though it's been available for 10 years across 80% of the installed base of the Internet? It's been a failure, for users, developers, and the font foundries themselves who have made no money even with the pseudo-DRM scheme that EOT currently has. It's time to try something new, and TTF is that new way.
  2. Why should fonts be treated differently than any other resource on the web? We currently don't have access controls for JavaScript files, HTML, images, text, MP3 files, etc., leaving that to legal mechanisms and technical systems out of band. One out of band solution to this is to use the HTTP Access Control spec; a font foundry could require you to use HTTP Access Control plus your TTF file through a legal contract. I already go through having to follow legal contracts when I use commercial stock photography, for example, or a Creative Commons image in a presentation or web site.
Chris Wilson is right that neither EOT or TTF are standards of any kind; they are both defacto standards, with the CSS Web Font mechanism being the real standard that all browsers now support. However, until the EOT camp can come up with answers to the two questions above (EOT has had 10 years -- why no adoption? and Why should web fonts be treated differently?) the debate about TTF versus EOT is over, with TTF having the clear verdict on the direction to move forward.
Email Post

Comments

CaptainN said…
There is an alternative that rarely gets any press - SVG Glyphs in an html context. This is currently supported by both Opera 10 and Safari 4 (proof: http://devfiles.myopera.com/articles/593/SVGfonts_in_HTML.html ).

I think there are the best way, and they even address some unmentioned concerns from your post.

1. EOT fonts have some advantages - DRM isn't one of them. They are supported by the 10,000 pound gorilla - that's huge. They are also a very small file format, subsetted and compressed. SVG Glyph support can address these concerns as well.

2. It isn't true that other forms of content are not protected at all (accept maybe text). They tend to be very heavily compressed versions made from professional source material - eg they are not suitable for re-use. Here again, both EOT and SVG Glyph fonts can provide a similar barriers to re-use since they are effectively the same thing, a stripped down version of the original content. PDFs and SWFs (Flash) have been doing that for ages.

On an interesting side note, the most recent version of Flash (version 10) now supports CFF font embedding (they call it DefineFont4), which if you can remember back to the Illustrator 7 days, used to be the preferred format for embedded fonts in SVG (it used to actually output a .cff file). :-)

Also, typeface designers tend to be old, and cranky. They are not ever going to be happy with any of the embedded technology, but I think it's time to give them something a bit less scary than let's embed .ttf or .otf files. It's an easier sell if the fonts linked by HTML are a type of file that cannot be easily taken and installed in the system font folder. EOT and SVG fonts provide that protection at least (flimzy as we techies know that protection is - at the very least, it takes a knowledgeable person to convert those fonts - just like flash and pdf embedded fonts).
1:06 PM
Post a Comment