Re: FW: EOT-Lite File Format

On Mon, Aug 3, 2009 at 11:41 AM, Dave Crossland<dave@lab6.com> wrote:
> 2009/8/3 Tab Atkins Jr. <jackalmage@gmail.com>:
>> (or
>> even goes further, and explicitly acknowledges that while rootstrings
>> were in the version of EOT that EOTL is based on, they're now part of
>> 'padding' and MUST be ignored)
>
> 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.
>
> Given many case studies of how DMCA-style laws are used to attack free
> software projects, and given browser developers said that EOT of yore
> posed too much DMCA risk, why does EOTL that allows ignoring
> rootstrings when present pose less risk?

I am not a lawyer, as I stated before.  However, EOTL does not *allow*
you to ignore rootstrings, it *requires* you to.  You are *required*
to treat any data specified as 'padding' as meaningless and take no
action based on it.  Thus you're not bypassing any restrictions,
because any rootstrings embedded in the 'padding' area of an EOTL file
*are not rootstrings*, and they're required to be ignored.

(This is based on a hypothetical EOTL version which is based on an EOT
version that allows rootstrings.  The current EOTL proposal from
Daggett is based on a version of EOT which does not have rootstrings
at all.)

> I assert that if the W3C promotes the distribution of files with root
> strings, it will compromise its credibility.

See above.  In the hypothetical EOTLwrip (with-rootstrings-in-padding)
format we're talking about, there are no rootstrings.  There is only
padding data which may be interpreted differently by certain legacy,
nonconforming browsers.

>> You put up a font.  Someone hotlinks it to
>> use on their own site.  What happens?  The font is completely ignored
>> on 30%-40% of browsers!
>
> Therefore EOTLs that contain a rootstring other than "*" ought to be
> rejected by EOTL-conforming browsers.

This doesn't seem to follow.

> This will not harm backwards compatibility with stale MSIE.

Indeed it won't.

~TJ

Received on Monday, 3 August 2009 18:17:24 UTC