RE: EOT-Lite File Format

On Friday, July 31, 2009 2:20 AM John Hudson wrote:
> 
> Vladimir wrote:
> 
> > As I understand what the current draft says
> > (http://lists.w3.org/Archives/Public/www-font/2009JulSep/0780.html),
> the
> > EOT-Lite conforming UA will render a font if it's capable to do so,
> > regardless of the presence of rootstring (i.e. completely ignoring
> the
> > root strings, whether mismatched or not).
> 
> It makes sense that the EOT-Lite proposal makes such a statement about
> EOT-Lite fonts. But, again, this presumes a distinction can be made
> between EOT-Lite and EOT-Classic fonts when encountered in the wild,
> because ignoring the rootstrings in a format that deliberately states
> that rootstrings should be ignored is different from ignoring
> rootstrings in a format that deliberately states that
> 
> 	User Agents must validate that the page using
> 	the embedded font is within the list of URLs
> 	from which the embedded font object may be
> 	legitimately referenced. [1]
> 
> I'm not a lawyer, but it seems to me that a browser that fails to
> follow
> this when encountering an EOT-Classic font is at legal risk. If not,
> why
> all the fuss about DMCA? At the very least, this seems to me a
question
> that needs to be examined by qualified lawyers experienced with this
> kind of issue.

If the behavior of EOT-Lite client matches what I described in my
previous email, then ignoring root strings poses no risk at all. As far
as EOT-Classic is concerned, I would consider the current EOT
specification as an "FYI" document, it is only a proposal and not an
official standard, and cannot be enforced in any way. The only document
that may ever get to the point when it can become a Recommendation is
yet-to-be-written EOT-Lite specification.

> 
> At present, the non-IE browser makers are deliberately not touching
EOT
> fonts because they don't want to get entangled with the rootstring
> issue. They're not supporting EOT but ignoring rootstrings: they're
> keeping the heck away from EOT altogether. It seems to me that they
> must
> continue to do so, because the status of EOT Classic fonts doesn't
> magically change when EOT Lite comes along.  This means that while EOT
> Lite fonts can be backwards compatible with IE<=8, EOT Classic fonts
> must not be forwards compatible with EOT Lite. Somehow the two formats
> need to be clearly distinct at the file level, such that an EOT Lite
> implementing browser can process the one but avoid the other.

I believe that the distinction line will be drawn based on capabilities
of the client to process a font; otherwise (again, based on the
reasoning I presented in my email earlier) I believe that simply
ignoring certain fields in EOT header is the best way to achieve truly
interoperable solution.

Regards,
Vlad


> 
> JH
> 
> 
> [1] http://www.w3.org/Submission/2008/SUBM-EOT-20080305/#RootString