W3C home > Mailing lists > Public > www-font@w3.org > July to September 2009

Re: EOT-Lite File Format

From: John Hudson <tiro@tiro.com>
Date: Thu, 30 Jul 2009 20:53:56 -0700
Message-ID: <4A726AD4.7050107@tiro.com>
To: Thomas Lord <lord@emf.net>
CC: Sylvain Galineau <sylvaing@microsoft.com>, www-font <www-font@w3.org>
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.

If someone puts a non-nil rootstring in an EOTL, a browser has three 

1. Ignore the rootstring, but this is tantamount to circumventing what 
someone has presumably included in the font as a DRM-enabling technical 

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.

Received on Friday, 31 July 2009 03:54:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:33 UTC