Re: CSS3 @font-face / EOT Fonts

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]