RE: EOT-Lite File Format

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.

Vladimir

> If someone puts a non-nil rootstring in an EOTL, a browser has three
> options:
> 
> 1. Ignore the rootstring, but this is tantamount to circumventing what
> someone has presumably included in the font as a DRM-enabling technical
> measure;
> 
> 2. Try to implement the rootstring, but is is acceptance of the
> DRM-enabling technical measure, which is precisely what browser makers
> do not want to do and why EOTL isn't supposed to have non-nil
> rootstrings; or
> 
> 3. Reject the font as being invalid due to non-conformance with the
> EOTL
> format specification.
> 
> Arguably, the legal risks associated with (1) are diminished if the
> format spec states that the rootstring is supposed to be nil and states
> that browser makers may ignore non-nil rootstrings and render anyway.
> But I'd take legal counsel on that, and also on whether the whole
> format
> spec runs the risk of being considered a circumvention of DRM-enabling
> technical measure (especially if ignoring the non-nil rootstring might
> also end up being applied to EOT fonts, as seems likely from the
> comments here).
> 
> Looking at it another way: at present the non-IE browsers will not
> display EOT format served typography because they do not want to deal
> with rootstrings. It seems logical then that they should continue to
> not
> deal with rootstrings and continue to not display served typography
> that
> contains rootstrings.
> 
> JH

Received on Friday, 31 July 2009 04:12:18 UTC