Re: FW: EOT-Lite File Format

On Mon, Aug 3, 2009 at 1:50 PM, Dave Crossland<> wrote:
> 2009/8/3 Tab Atkins Jr. <>:
>> On Mon, Aug 3, 2009 at 11:41 AM, Dave Crossland<> wrote:
>>> I see no difference between a browser that implements EOT as submitted
>>> to W3C 18 months ago and ignores root strings, and a browser that
>>> implements EOTL as submitted to W3C in 6 months time and ignores root
>>> strings when it sees them.
>> any rootstrings embedded in the 'padding' area of an EOTL file
>> *are not rootstrings*
>> ...
>> In the hypothetical EOTLwrip (with-rootstrings-in-padding)
>> format we're talking about, there are no rootstrings.
> 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
are different things.

I mean, honestly, did you really think I was contradicting myself
within-sentence *twice*?

>> There is only
>> padding data which may be interpreted differently by certain legacy,
>> nonconforming browsers.
> Your proposed W3C Recommendation says that these rootstrings are mere
> padding. A font vendor has distributed a million EOTLs with such mere
> padding containing rootstrings for stale MSIE. They are nearing
> bankruptcy and have only enough equity left to hire some lawyers and
> sue a wealthy browser developer before any more activity risks
> becoming fraudulent trading. Welcome to the collapse of the American
> empire!

It's not like we can stop idiots from suing whomever they wish and
wasting everyone's time and money.  If that's your definition of
collapse, then America's been long gone.  ^_^

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.


Received on Monday, 3 August 2009 19:14:22 UTC