Re: cutting to the chase

On Mon, Aug 3, 2009 at 1:13 PM, Thomas Lord<> wrote:
> Tab, this is an interesting area: can consensus
> be reached on EOTL without EOTC?  There
> seems to be a subtlety here that I think
> many have missed but that is clear from earlier
> discussion.  Looking at your take on it:
> On Mon, 2009-08-03 at 09:47 -0500, Tab Atkins Jr. wrote:
>> On Sun, Aug 2, 2009 at 7:20 PM, Thomas Lord<> wrote:
>> > 2) Consensus on EOT-classic (with or without
>> > rootstring enforcement, MTX, and so forth)
>> > is unlikely to ever be reached.
>> Correct on this.  The non-IE browsers have made it clear that they
>> will not support EOT.
>> > 3) Consensus on EOTL variants is unlikely
>> > to ever be reached.
>> Completely incorrect.  Daggett and Galineau (from Mozilla and MS,
>> respectively) are producing an updated EOTL spec on the list as we
>> speak, and the issues we're arguing over are fairly minor.  The worth
>> of supporting EOTL in general seems to be relatively evident to a good
>> number of people.
> You seem to me to be confusing two issue:
> I agree with you that proponents of EOTL will
> likely soon find consensus among themselves on
> a definition for EOTL.  Perhaps they already have.
> What appears to be unresolvable, though, is
> whether a Recommendation that says "MUST"
> have EOTL support says:
>  a) MUST NOT support EOTC
>  b) SHOULD support EOTC (ignoring rootstrings)
>  c) MAY support EOTC (ignoring rootstrings)
>  d) says nothing about EOTC
>  e) says SHOULD or MAY support EOTC (honoring rootstrings)
> EOTL proponents seem to insist upon (a), (d), or (e).
> The concerns about EOT in general being a DRM trap
> are alleviated only by (b) or perhaps (c).  So
> there is a neat and profound partition of viewpoints here.

You are under the mistaken impression that EOTClassic has rootstrings.
 It does not.  (See, and
contrast it with the versions following in the document.)  Thus,
EOTL1.1 (the current proposal from Daggett) also has no rootstrings of
any kind, even hidden in padding.

Even with EOT2.1 or 2.2 (the one with rootstrings) and EOTLwrip
(with-rootstrings-in-padding), (b) and (c) aren't necessary as long as
there's a way to distinguish between the two formats in conformant
parsers.  The point of EOTL (either version) is that legacy parsers
will think that the file is the corresponding EOT version, and thus
render it.  Conformant browsers, however, should be able to
unambiguously distinguish between the EOTL file and the EOT version it
is based on, and thus tell whether it should honor or ignore the
rootstrings in the file (again, assuming EOTL2.1/2.2 and EOTLwrip, as
EOTClassic and EOTL1.1 have no rootstrings at all).

>> I hate this fact, but there are lots of things about reality that I
>> hate.  It doesn't go away when I refuse to believe in it, though.
> A reality that will not go away is that if you
> grant a single firm de facto dictatorial power
> over W3C Recommendations then you make a farce out
> of the W3C process.  In the bigger picture, the
> disposition of font support in IE is less important
> than that political question.

Apologies: you are confusing my objection.  I don't object to such a
Proposal, because I don't *care* about Proposals.  I'm an author.  I
care about standards.  Standards exist *only* in "de facto" terms -
they're a standard if and only if they are implemented widely enough.
In my worldview, proposals and such exist only as locuses around which
standards can emerge.

So I could care less if a proposal for TTF linking was created,
Objections were answered, and the Director sanctified it, if IE
vocally refuses to implement it.  It's not a standard, and it doesn't
help me do my job, because fonts are important enough to designs that
being unable to make them work in IE means I can't use them at all.


Received on Monday, 3 August 2009 19:03:47 UTC