Re: EOT-Lite File Format

On Thu, 2009-07-30 at 20:53 -0700, 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.


If what you say sticks, then EOT-lite won't pass
(is my opinion about both what is right and what will
likely happen).

-t



>  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.
> 
> 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:49:24 UTC