RE: EOT-Lite clarification

I am fine with it. I agree with Rob that ignoring rootstrings and applying the “same-origin check + CORS” is the best deployment scenario compatible with legacy IE implementations. And the fact that even some existing EOT files (without obfuscation and compression) might work is only a benefit.

 

Cheers,

Vlad

 

 

From: Sylvain Galineau [mailto:sylvaing@microsoft.com] 
Sent: Monday, July 27, 2009 8:13 PM
To: robert@ocallahan.org
Cc: Levantovsky, Vladimir; John Daggett; www-font
Subject: RE: EOT-Lite clarification

 

OK, I see where you (and Vlad earlier) are going with this. Sorry I was slow. So EOT-Lite would become

1.       EOT with no compression or obfuscation.

2.       A web client conforming with EOT-Lite must:

a.       Ignore any rootstrings

b.      Apply a same-origin check, allow CORS override

3.       The font user may use EOT’s rootstring field to enforce same-origin policy for all IE releases up to and including IE8.

 

Did I get it right this time ?

 

This does open up the possibility that a client conforming with EOT-Lite will be able to load existing EOT files with a roostring set to any value as long as the font data is neither compressed nor obfuscated. My understanding is that products licensed to EOT so far have typically used one or both. Such files would fail to load in non-IE browsers just like they fail today i.e. the font file would be treated as corrupt and ignored.

 

Vlad, Bill, feedback ?

 

From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of Robert O'Callahan

 

On Tue, Jul 28, 2009 at 9:57 AM, Sylvain Galineau <sylvaing@microsoft.com> wrote:

 > I do not see why one would even have to check that rootstring is null.
 > Would it be easier just ignore it no matter what (if anything) is in
 > there? And, if this is what the spec say browser should do (i.e. ignore
 > rootstring), I don't see anything wrong with it, it just makes
 > implementer's life easier.

 I'd think anyone who licenses EOT-Classic fonts (as opposed to EOT-Lite)
 expects the rootstring to be enforced. Even if Monotype doesn't care it
 would be quick check, combined with a file extension, indicating that
 you're dealing with a valid EOT-Lite file and can go straight to the font
 data. No MTX compression or any other legacy feature in your way.


IMHO EOT-Lite would be more attractive specified as "clients should ignore rootstrings, but apply a same-origin check + CORS" than with "clients must reject a non-null rootstring, but apply a same-origin check + CORS" ... because it enables the deployment scenario where access is controlled with a rootstring for IE<=8 and same-origin + CORS for other browsers. I believe that is the best deployment scenario that is compatible with IE<=8.

If the ignore-rootstrings version of EOT-Lite is untenable due to concerns over EOT-Classic fonts, then we need to hear that now.

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]