Re: CSS3 @font-face / EOT Fonts

I'd like to express agreement with Robert's comments. I also would  
like to correct a few additional factual errors in the summary:

> Håkon also convinced YesLogic (in 2007) and Apple (in 2008) to  
> implement font linking (without embedding), in Prince and Safari,  
> respectively.

Apple's decision to implement Web Fonts was not to any significant  
extent due to Håkon's advocacy, but rather because we feel it is an  
important feature for the Web platform.


> Apple's Safari has implemented font download with no checking of  
> licenses. They said they are against EOT and against browsers  
> checking licenses.


I'd like to clarify that we are not against making font references  
restricted to same-origin by default, with Access-Control supported to  
enable loosening this restriction. This is compatible with Mozilla's  
position. We think same-origin restrictions by default are reasonable,  
but we do not want to be in the business of enforcing third-party  
license terms.

Bert, I'd appreciate if you could correct these points as well as the  
points raised by Robert below.


I share Robert's concern that Bert appears to have already decided in  
favor of EOT. For most of the critiques of EOT that the summary  
presents, the critique itself is stated as the position of others  
("Some implementers expressed fear...", "Another critique...", "Many  
people classify...", "Microsoft's competitors naturally claimed") but  
presents rebuttals to these criticisms in authorial voice as  
statements of fact. I don't see any way to interpret this but that the  
author of the document has taken sides.

I would like to remind Bert and others that EOT remains a Microsoft- 
only technology, and will likely remain so regardless of its status as  
a W3C standard. I share the feeling expressed by many that the W3C  
should focus on interoperability and technologies that are likely to  
see wide cross-browser implementation.


Regards,
Maciej


On Oct 16, 2008, at 9:48 PM, Robert O'Callahan wrote:

> For the record, here are my comments on Bert's summary --- perhaps  
> "the other side of the story" :-).
>
> 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.
>
> This is not a fact. It is purely speculation. The poor quality of  
> Microsoft's WEFT tool and the lack of interoperability with other  
> browsers are just as likely to have been major factors.
>
> 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.
>
>
> As I pointed out in my message to member-eot-review, EOT actually  
> binds fonts to URL prefixes, not particular documents, and its  
> advocates recommend binding fonts to entire domains --- the same  
> binding scope that we propose be the default for bare font files via  
> a same-origin restriction. Calling one approach "embedding" and  
> another approach "linking" attempts to create a distinction where  
> none exists.
>
> Subsetting and compression without embedding
> 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.
>
>
> It's just as easy to subset a font and call it "Superfont- 
> Subset.otf". Making the file format different adds no value.
>
>
>
> Ease of use
> If you have a free font you could just upload it and point CSS at  
> it. EOT would require converting 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.
>
>
> Here Bert is presupposing that non-"free" fonts cannot be used as  
> bare font files, i.e., that the "font embedding" licensing cannot  
> apply to bare font files, but it can apply to EOT. That is in fact a  
> core issue under dispute. I think Bert is exposing that he has  
> already decided in favour of EOT.
>
> One key ease-of-use issue not raised by Bert is what happens when  
> you move a collection of files from one domain to another. With EOT,  
> the font files will probably need to be regenerated or modified.  
> With bare font files and a same-origin restriction, files do not  
> need to be modified. This is very important because a lot of Web  
> developers test their changes on a "staging server" before deploying  
> on the real server, and adding steps to the deployment process is  
> inconvenient and introduces risk of regressions going into production.
>
>
>
> 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 required 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.
>
>
> This is a misunderstanding. No additional work on the Access- 
> Controls spec is required to apply it to fonts. It was designed to  
> be reused in situations such as this. Also, Access-Controls itself  
> does not need to be aware of licensing; it simply provides a  
> mechanism which authors can use to relax the (default) same-origin  
> restriction when font licenses allow them to.
>
>
> 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.
>
>
> The only practical difference in the association between the font  
> and the document is that downloading a font file and uploading it  
> for use in another domain requires an extra step with EOT --- the  
> RootString must be modified. But that step is very easily automated  
> --- as Bert acknowledges below in his comments on "DRM".
>
> The Silverlight argument
> 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.
>
>
> This is incorrect. Silverlight 2 is completely capable of using bare  
> font files, either packaged in the application ZIP file or at  
> standalone URLs in the same domain, via the WebClient interface.  
> Silverlight 2 does not support EOT.
>
> Furthermore, Silverlight developers are exhorted to respect font  
> licensing restrictions, but Microsoft's internal conclusion that  
> "font embedding" permissions do not apply to Silverlight  
> applications does not seem to have been communicated to Silverlight  
> developers.
>
>
>
> 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.
>
>
> EOT still requires "XOR encryption" of the font file data, plus  
> checksumming of the RootString field, presumably to make extraction  
> of the font data or modification of the RootString more difficult.  
> But both are worthless for this or any other purpose, and simply add  
> complexity for no gain.
>
> Microsoft has said that it is impossible for them to support linking  
> to native OpenType as long as font vendors oppose it.
>
> As far as I know, font vendors have not been offered the option of  
> bare font files with same-origin restrictions, so it is unclear if  
> font vendors oppose it.
>
>
> 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.
>
> 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.
>
>
> This is a misconception. EOT, as implemented by Microsoft, does not  
> distinguish between readonly and editable documents. Besides, if the  
> font was made available in EOT, someone could easily extract the raw  
> font, as Bert has already pointed out.
>
> Rob
> -- 
> "He was pierced for our transgressions, he was crushed for our  
> iniquities; the punishment that brought us peace was upon him, and  
> by his wounds we are healed. We all, like sheep, have gone astray,  
> each of us has turned to his own way; and the LORD has laid on him  
> the iniquity of us all." [Isaiah 53:5-6]

Received on Friday, 17 October 2008 08:09:24 UTC