Re: FW: EOT-Lite File Format

2009/8/3 Tab Atkins Jr. <>:
>> 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?

> 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.  ^_^

What I mean is, as the geopolitical landscape transitions from the
unipolar world to a multipolar world, a lot of formerly powerful
companies are going to get scrappy, and we might well see some
software companies in that trend, and maybe even some involved in this
little storm in a teacup :-)

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

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? :-)

2009/8/3 Sylvain Galineau <>:
> I am most comfortable with an alternative that does away
> with rootstrings entirely, cleanly segregating EOT files
> with embedded access restriction capabilities from
> EOTLs without any. If authors and font vendors see
> that as a problem, we can revise the proposal.

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