Re: EOT-Lite File Format

Vladimir wrote:

> I disagree. As far as browsers implementing EOT-Lite are concerned, there is a variable-length padding that they need to skip because it has no meaning for them. This is the only thing that is defined in the spec, the fact that in the original EOT spec the same field used to contain root strings, font family name, style and other data is irrelevant here. There can be no circumvention if you ignore a data field with unknown content, and you do it according to the specification you implement.

But the browsers are implementing EOT *Lite*, but may encounter EOT 
*NOT*-Lite, i.e. existing EOT-Classic fonts -- to use Sylvain's term -- 
targeting IE<=8 with rootstrings. These are *not* EOT Lite fonts: they 
have not been licensed for use as EOT Lite fonts, they have been put 
online with the expectation that their rootstrings will be respected as 
per IE's existing implementations.

This is why, earlier today, I suggested that it was necessary for 
browsers to be able to distinguish EOT Lite fonts from EOT fonts. To 
which you responded

 Strictly speaking, this is not necessary. The
 EOT-Lite format, as outlined by John Daggett,
 allows browsers to simply skip all fields of
 EOT header that are irrelevant for EOT-Lite.

Which I interpret to mean that EOT-Classic fonts will be treated as if 
they are EOT Lite. And that seems to me problematic.


JH

PS. I'm offline for the next couple of days.

Received on Friday, 31 July 2009 06:05:26 UTC