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