RE: EOT-Lite File Format

On Friday, July 31, 2009 2:05 AM John Hudson wrote:
> 
> 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.

Here is why I think it should not be a concern:

- currently, EOT is not a W3C standard, and the expectations that root strings would work can only be relevant for existing IE implementations - in this regard they will continue to work just fine.

- browsers implementing EOT-Lite will apply same-origin restrictions by default. If root strings in EOT file are there for that same reason - both implementations will do exactly the same things. It's also may happen that root strings may have been used to relax same-origin restriction (i.e. to permit font be linked from certain other domains) - in this case web author will find out that although EOT font works fine in IE, EOT-Lite implementations are *more* restrictive and require additional CORS headers be in place to achieve the same functionality on EOT-Lite compliant UA.

- most of existing EOT fonts are likely to be XOR-encrypted and/or compressed, and EOT-Lite compliant UA may not be able to process them anyway.

> 
> 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.

If the UA behavior is compliant to what I described above, I would say that skipping irrelevant fields in EOT header is the least problematic way to implement EOT-Lite.

Regards,
Vladimir

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

Received on Friday, 31 July 2009 15:40:00 UTC