RE: EOT-Lite File Format

>From: John Hudson [mailto:tiro@tiro.com]


>Sylvain wrote:
>
>> So either EOTL clients check for nil-rootstrings (wrecking the
>possibility of
>> hijacking them for same-origin checks in legacy IE)...
>
>I kind of assumed that EOTL clients would check for nil rootstrings, and
>that a non-nil rootstring would make it an invalid EOTL.

I did too. But if a license does require same-origin checks then it was assumed
a customer might want to use the rootstring to do that for the IE installed base.

The irony there is that we initially started with the assumption that rootstrings
are just not practical at all to manage...


>Whatever else it is, an EOT Lite font is a font with a nil rootstring
>[at the moment, it is also a font with no compression, but I'm really
>hoping that we can get this to a working group stage and satisfy
>Monotype's criteria for releasing the MTX patented compression].

Patent or not, I don't think there is much interest in implementing this.
One can still compress the font on the wire using HTTP gzip.


>Font makers are going to be licensing fonts for EOTL format linking, not
>EOT linking. And most of those makers, I suspect, will also be providing
>the EOTL files to the customer. Microsoft's original EOT model, whereby
>which the web author created his own .EOT files from TTFs only made
>sense because of the rootstrings and content-specific subsetting,
>particular to the use of the font on specific websites. Since there are
>no rootstrings in EOTL, and content-specific subsetting is no longer
>viable since web content is now a lot more dynamic than it was in 1990,
>I anticipate .EOTL -- or any other web font format -- being primarily a
>delivery format from font makers to licensees of web fonts.

My expectation also. Which is why I'd rather have a nil rootstring for all
EOTL files in existence. But if EULAs do require same-origin check then
supporting IE is a lot less of a benefit since you either need a way to
use that roostring after all, or use HTTP Referer or other server-side
mitigations.

Received on Friday, 31 July 2009 00:14:22 UTC