Re: EOT-Lite File Format 1.2 (was RE: EOT & DMCA concerns)

On Tue, Aug 4, 2009 at 3:16 PM, Levantovsky,
Vladimir<Vladimir.Levantovsky@monotypeimaging.com> wrote:
> Introducing the new version number for EOT-Lite and requiring all EOT-Lite compliant implementations to support the new files with version number *only* should eliminate any concerns about hypothetical presence of rootstrings in padding, IMO. We define a new format with no notion of rootstrings, and the new version number provides a clear way to differentiate any and all prior EOT formats and the new EOT-Lite.

I can see Sylvain's point.  EOTL1.1 is a strict subset of EOT-Classic,
that is to say, there are some files which are both valid EOTL1.1
*and* EOTC, and can validly be parsed as either.  The way EOTL1.1 is
set up, though, there shouldn't be any legal issues arising from
accidentally parsing an EOTL1.1 as an EOTC, or vice versa.

EOTLwrip is a different story, which is why the different version
number is a necessity.  It's a requirement for practical legal reasons
that an EOTLwrip consumer be able to recognize and reject any and all
EOT-with-rootstrings files (if it wishes - it's always allowed to
support EOT-with-rootstrings as well if it wants).

So Sylvain's basically saying that the different version number isn't
required for EOTL1.1, but it would be if they changed the EOTL
proposal to be based on one of the EOT-with-rootstring formats.

~TJ

Received on Tuesday, 4 August 2009 20:29:27 UTC