Re: EOT-Lite File Format v.1.1

On Fri, 2009-07-31 at 12:56 -0700, John Daggett wrote:
> Thomas, I really don't follow anything you're saying.

It's just some simple questions, in spite
of the heat that some have generated in
response.

The informal EOTL proposal language says to check
the version number and certain bits and says
that if these checks don't pass then the "font
is not loaded".

The original question was and remains whether
that "is not loaded" implies formal Recommendation
language that says "MUST NOT load", "MAY load", 
or "SHOULD load".

The language "MUST NOT load" would make this what we
have been calling a "DRM" proposal.  The language
"MAY" or "SHOULD" would fix that.  The language
"MAY" or "SHOULD" would require the patent de-encumbering 
of MTX.

I don't sense that MicroType would be especially 
unhappy if MTX were de-encumbered in that case.
Indeed, it would put at least a little pressure
on Mozilla and other browser implementers to support
it even though support for it were not a "MUST"
in an EOTL recommendation.   I don't sense that
Ascender has any deep objection to "MAY" or "SHOULD".

I quite honestly raised the issue initially in 
hopes of getting quick assent from Ascender to 
reading their proposal as saying "SHOULD load"
rather than "MUST NOT load".  In ordinary English
that sounds like a complete reversal but in the 
language of a standard, it's a much smaller change.

It seemed like just an incremental suggestion in
the direction of making a concrete draft Recommendation.
It didn't seem, at the time, like it would be particularly
controversial at all.  It seemed, at the time, like it 
would help to move dialog towards the nitty gritty of 
what a draft would specifically contain.  It seemed,
at the time, like a way to double-check the general
sense that we were, most of us, nearly on the same page.
And then Sylvain spoke up, peppering his messages with
insults.


> We're trying to define a simple format that just happens to work in
> IE.  EOT-Classic, MTX compression and XOR-swizzled data is something
> for IE to worry about. 

I don't think that a font Recommendation that says
"make sure this isn't EOT classic OR ELSE" will fly.
It would be a very bad precedent.  Somewhat perversely,
given the presence of the MTX bit, that means MTX 
should be part of the deal (while, as a community, 
we try to minimize the logistical costs of that to
MicroType in reciprocation for their contribution).


>  Versions of IE <= IE8 will not be "conformant"
> implementations of EOT-Lite (e.g. no same origin check, data in the
> padding fields dictate load behvavior) but future versions will.

The same-origin or CORS non-conformance of IE <= IE8 is 
an orthogonal issue to the potential file format conformance
of IE <= IE8.

> EOT-Lite is defined in such a way that the fonts will still render in
> IE4-IE8, it's this backwards compatibility that has been put forward
> as the motivation behind this format.

I'm fully aware of that.


> If you want to propose something else, EOT-Thomas, fine, do so.  But
> suggestions that non-IE browser vendors want/should/could/might/desire
> to support EOT-Classic fonts are way off track.

I am more concerned with what the Recommendation
might say UAs "MUST" or "MUST NOT" do than I am 
with what a handful of contemporary UA makers intend
at this moment to do.

-t

Received on Friday, 31 July 2009 21:31:53 UTC