Re: EOT-Lite File Format

On Thu, Jul 30, 2009 at 11:12 PM, Levantovsky,
Vladimir<Vladimir.Levantovsky@monotypeimaging.com> wrote:
> On Thursday, July 30, 2009 11:54 PM John Hudson wrote:
>>
>> Thomas Lord wrote:
>>
>> >> It has been repeatedly stated that the latest proposal is to limit
>> >> EOTL to a header version (2.0) that contains no rootstrings.
>>
>> > What is to be required of a UA encountering a file
>> > which can be processed in the manner of EOTL but
>> > for the fact it contains a root string?  You seem
>> > to say that you expect conforming UAs to not render.
>>
>> Yes, because to do otherwise would be to risk circumventing a technical
>> measure intended to restrict rights. Ignoring a non-nil rootstring is
>> exactly the situation that the browser makers do not want to be in,
>> because that is DMCA territory. Rejecting a font with a non-nil
>> rootstring as being *invalid* -- which is different from rejecting it
>> as
>> a result of trying to implement the non-nil rootstring and finding that
>> it doesn't match the source -- is actually the only safe thing to do in
>> this situation.
>>
>
> 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.

Vlad's got it.  An EOTL file *has no rootstring*.  Anywhere.  The
concept of rootstrings does not exist, any more than TTFs have
rootstrings.  There's just an opaque, variable padding at the start of
the file, and a few variables.

The fact that EOT consumers can find some bytes in that opaque padding
that correspond to their notion of 'rootstring' is nothing more than a
convenient coincidence.  An EOTL file (which can be affirmatively
distinguished for an EOT file now, by the version number) cares not a
whit for such concepts.  Thus, neither do conformant clients.

Received on Friday, 31 July 2009 13:13:43 UTC