Re: EOT-Lite File Format

Sylvain Galineau wrote:

> 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.

Than the customer should serve EOT to those browsers, not EOTL.

> 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.

One can, but you were the one who concluded

 This being said, a compressed file format is
 optimal. Compress the data once, never configure
 a server. [1]

after the discussion about server-side compression.

> 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.

If a nil rootstring is a requirement of the EOTL format, and if EOTL 
conformant browsers will not display EOTL fonts with non-nil 
rootstrings, then web authors wishing to use fonts with such a EULA 
requirement will have to employ HTTP Referer or other server-side
method, presuming that they want the fonts to be displayed in EOTL 
conformant browsers.

If this is what the spec says, and this is what conformant browsers do, 
then problems of single-origin checking and are an issue between the web 
author and the font maker. ISPs are already going to be a third party in 
this, insofar as they enable or do not enable the web author to 
implement server-side checking, and I don't see any benefit to making 
the browsers a fourth party by allowing their behaviour to be ambiguous 
or unpredictable.

Really, it is in everyone's interest for nil rootstring checking to be 



Received on Friday, 31 July 2009 00:39:48 UTC