RE: EOT-Lite File Format v.1.1

On Friday, July 31, 2009 4:20 PM Tab Atkins Jr. wrote:
> On Fri, Jul 31, 2009 at 3:11 PM, Sylvain
> Galineau<sylvaing@microsoft.com> wrote:
> 
> > Vlad and Roc, however, have stated their preference for preserving
> the rootstring option
> > for IE use only e.g. to allow authors to comply with EULA same-origin
> mandates. As
> > I don't have EULAs to look at, and the very impractical nature of
> rootstrings was one
> > of the main arguments against the EOT restriction model, the feature
> is effectively gone
> > for the time being. Not just disabled or ignored but absent.
> 

I believe Roc and I didn't state any preference for rootstring option, but instead suggested to simply ignore the whole "padding4" field without ever paying attention to what could be encoded there.

> > Of course, this means that IE<=8 may enable hotlinking if server-side
> measures similar
> > to those used for other resource types are not in place. I'm looking
> into what checks,
> > if any, were done for this version of the format...
> 
> Yup, this is why being *capable* of embedding a rootstring for
> downlevel clients is useful - it's relatively easy to employ in a
> limited fashion for downlevel clients, it's just really annoying to
> have to deal with all across one's toolchain.  Foundries that don't
> place that kind of responsibility on the client can ignore it
> entirely, and once IE<=8 share drops enough it won't be worth worrying
> about (any more than the fact that wget, etc. can simply ignore
> same-origin restrictions if they choose).

I suggest that in order to clearly separate EOT-Lite fonts while at the same time give authors the option of "being *capable*" to address the issues they may face, we should assign a new version number for EOT-Lite, e.g. 0x00020003 and make no assumptions about what could be encoded in the variable-length "padding4" (as we do today). This should provide a clear indication that we are dealing with the new type of font object for EOT-Lite, while IE<=8 would still be able to process the data as traditional EOT file.

Starting with IE=9 this new version will be supported with the same-origin restrictions + CORS, so that we can gracefully transition from "legacy compatible" solution to something that is universally interoperable in all browsers.

Sylvain, would this work for IE<=8?

Thank you,
Vlad

> 
> ~TJ

Received on Saturday, 1 August 2009 01:11:55 UTC