Re: FW: EOT-Lite File Format

On Tue, Aug 4, 2009 at 10:20 AM, Dave Crossland<dave@lab6.com> wrote:
> 2009/8/4 Thomas Phinney <tphinney@cal.berkeley.edu>:
>> On Mon, Aug 3, 2009 at 3:05 PM, John Hudson<tiro@tiro.com> wrote:
>>> EOTC fonts should be completely ignored by all browsers except IE. It should
>>> be obvious that this is actually in the interests of the EOTL format,
>>> because if EOTC fonts are not interoperable with other browsers, this
>>> encourages both font makers and authors to use EOTL instead. If, on the
>>> other hand, non-IE browsers treat EOTC fonts as if they are EOTL, then such
>>> fonts will stick around much longer, just waiting for someone to sue the
>>> browser maker or the W3C for circumventing the rootstring mechanism in EOTC.
>>
>> I agree. If I were an open source and free software advocate, I would
>> have zero interest in having my browser support EOTC.
>
> Hang on. I just reread Tab and Tom Lord's posts on this, and it seems
> to me they are saying there are 4 things that the W3C Recommendation
> ought to be backwards compatible with, if backwards compatibility is
> an important aim here:
>
> 1. Existing versions of MSIE
>
> 2. Existing EOTC-using websites
>
> 3. Existing versions of Firefox, Safari, and real soon Opera and Chrome
>
> 4. Existing TTF-using websites
>
> We've heard assertions that 4 is small enough to trample on, and 3
> will kill the type designers business because no one will buy font
> licenses anymore if that happens, and that 1 is a very good idea.
>
> I think Tom and Tab are saying that 2 is not small enough to trample
> on, and just saying to such sites "tough, upgrade to EOTL" is not a
> credible move for the W3C; especially since, as ROC points out, even
> Ascender's own license requires things EOTL doesn't deliver.

Not quite.  Tom seems to be asserting that we need backcompat with 2,
and I'm questioning him on why.  I don't believe we need anything of
the sort - those sites are *already* expecting their fonts to only
work in IE, so there's no compelling reason to require other browsers
to step up.

IE will, of course, continue to support EOTC in all variants for some
time (at least that's the impression I got from some of Sylvain's
comments).

> If the W3C Rec is only backwards-compatible with MSIE and not other
> browsers TTF web fonts features, and smashes up existing sites using
> EOTC, it is not "Leading the Web to Its Full Potential" - it is
> breaking existing sites that serve people who are AFAICT
> underrepresented in our discussions, and most importantly the W3C is
> now giving preferential treatment to a single vendor, Microsoft.

It would not be breaking a single thing.  Any breakage has already happened.

There is no preferential treatment.  There is a realistic use-case
being addressed - whole lots of users have browsers which support
@font-face with a particular format, so building a compatible format
benefits us authors.

I would *love* TTF support interop as well, but that's not widely deployed yet.

> To give uniform fair treatment would be to Recommend browsers support
> both existing web font formats, EOT and TTF, and allow browsers to run
> the risk of breaking the DMCA-style laws and ignoring root strings but
> still rendering files with root strings - if the W3C says the root
> strings are padding or not doesn't effect that they are in the files
> and are being ignored, and to ignore files with rootstrings will not
> be backwards compatible with existing EOTC sites.

You're still running off some wrong assumptions.  Let's see if I can
put these things to rest once and for all.

1) There are multiple versions of EOT (3, to be precise).  Two of them
have rootstrings.  One does not.

2) The current EOTL1.1 proposal by Daggett is compatible with (based
off of) the version of EOT without rootstrings (commonly called
EOTClassic, or EOTC).

3) Some original proposals bandied about (and still being discussed)
would build EOTL on a version of EOT with rootstrings.  This would
enable us to include rootstrings in the padding area to simulate
same-origin, so legacy IEs would treat them like EOT files and obey
them, while conformant browsers would treat them like EOTLs, ignore
anything in the padding, and apply same-origin restrictions.  I've
been calling these versions EOTLwrip (with-rootstrings-in-padding).

4) Nobody (except maybe Lord, I'm not sure yet) is proposing that
browsers accept EOT files with rootstrings, but ignore the
rootstrings.  This is likely to invite legal repercussions.

5) EOTL files can be reliably distinguished from the EOT versions they
were based on.  A conformant browser can unambiguously tell "this file
is EOTL, so I must ignore anything in the padding areas" or "this file
is EOT, so I need to pay attention to the information in the header,
or else just dump it if I don't want to support that stuff".  A
conformant browser cannot recognize the file as EOTL and then pay
attention to the padding area, and a browser which wishes to protect
itself from legal threats cannot recognize the file as EOT and then
ignore the header information.

6) The EOTL format is created in such a way that legacy IEs *cannot*
distinguish them from EOT.  That's fine, it just makes legacy IEs
nonconforming.  In the case of EOTL1.1, there is no legal risk.  In
the case of EOTLwrip, some people have argued that there is a legal
risk, but others (me included) are rather sure there is not.  The
argument for risk goes like "Rootstrings exist in the header, even if
the format says that's just meaningless padding, so ignoring them
opens you to lawsuits."  The argument against is "The information in
the padding area is *defined* to be meaningless and is commanded to be
ignored, and there is no chance for a conformant implementation to
accidentally interpret an EOT file (where the rootstring is supposed
to be obeyed) as an EOTL."

Does all of that help?  Are there further questions?

~TJ

Received on Tuesday, 4 August 2009 16:03:51 UTC