RE: EOT-Lite File Format v.1.1

On Fri, 2009-07-31 at 18:04 +0000, Sylvain Galineau wrote:

> I honestly don't understand what's being evaded. EOTL files
> have no rootstrings. There is not space for them in the header.
> EOT files with rootstrings are, per the current definition,
> not EOTL files. IE will still support those. But an EOTL-only
> implementation will treat any EOT files with rootstrings as
> invalid since the header version number will be != 0x00020000.
> 
> Sorry for being dense. I don't understand what the issue is.

No problem.  You nicely explained your question
and I hope that this answer is helpful:

You say "an EOTL-only implementation will treat any EOT
files with rootstrings as invalid since the header version
number will be != 0x00020000"."

I presume you would say that a file with the XOR or MTX
bit set would also be "treated as invalid".

The question concerns what "treated as invalid" means
in these cases.

The question arises because, technologically, it is a 
fairly trivial matter for a UA to treat the invalid EOTL
as a font which can be rendered.  A reasonable UA, 
recognizing that such files are found "in the wild", might
choose to go ahead and render with the font - decompressing
from MTX if necessary and ignoring a non-nil root string
if necessary, disregarding (or recognizing) the non-EOTL
version number.

Yet there is a concern here that a UA which does so
may be accused of violating one or more patents,
of being a part of contributory infringement, or perhaps
even being a circumvention device.

Therefore I (and I guess Tab) are asking for a positive
assertion both here and in any eventual Recommendation
that a UA is free to treat such "invalid" EOTL in the 
manner I described - decompressing, ignoring root string,
rendering, and so forth - without risking violating a 
patent or being accused of contributory infringement or
being a circumvention device.

-t

Received on Friday, 31 July 2009 18:17:03 UTC