Re: FW: EOT-Lite File Format

On Mon, Aug 3, 2009 at 2:25 PM, Dave Crossland<dave@lab6.com> wrote:
> 2009/8/3 Tab Atkins Jr. <jackalmage@gmail.com>:
>>>
>>> Any rootstrings are not rootstrings.
>>>
>>> In the with-rootstrings-in-padding format there are no rootstrings.
>>>
>>> 2 + 2 = 5.
>>
>> Dude, put scarequotes around the appropriate parts if you want.  You
>> know what I meant.  Rootstrings-intended-to-be-enforced and
>> padding-data-that-looks-like-rootstrings-from-the-corresponding-EOT-format
>> are different things.
>
> You see they are different; the W3C Recommendation can assert they are
> different; but courts in nasty jurisdictions that signed the WIPO DRM
> treaty and brought in DMCA-style laws may not see what you see.
>
> Qui desiderat?

An actual recommendation would phrase things differently.  It wouldn't
mention rootstrings *at all*, it would just say, "Here's the format,
these bits must be set in this way, and these bits are just padding
and will be ignored.".  I just mention that in my email for clarity
and comparison purposes.

If you've distributed EOTL files, you have only the EOTL spec to point
to on how it should be used.  The spec will have absolutely nothing to
say about 'rootstrings'.

>> However, the EOTLwrip spec will say there are no rootstrings (there's
>> just padding data that must be ignored).  EOTL1.1 has no *possibility*
>> of containing 'rootstrings', in padding or not.  All modern browsers
>> will correctly ignore such 'rootstrings' lying in the ignored padding
>> area of EOTLwrip.  There's no case there.
>
> Will they ignore the root string, or ignore the file containing rootstrings?

In EOTL1.1 (Daggett's current version), an EOTL with rootstrings is
formatted completely wrong.  A consumer will try and grab the
fontdata, and end up getting some garbage at the beginning as well.

In EOTLwrip, it is part of padding and has no meaning, and consumers
are required to take no action based on the contents of the padding
(this is also true of EOTL1.1, it's just got a slightly different
padding structure).

> When Sylvain says "Cleanly segregating EOT files with embedded access
> restriction capabilities from EOTLs without any" gives me hope that it
> is the latter; Sylvain, could you confirm this explicitly? :-)

Yup, EOTL1.1 has no access restrictions, so as currently proposed
there is a clear distinction.

~TJ

Received on Monday, 3 August 2009 19:35:50 UTC