Re: EOT-Lite File Format v.1.1

On Fri, 2009-07-31 at 16:42 -0500, Tab Atkins Jr. wrote:
> On Fri, Jul 31, 2009 at 4:34 PM, Thomas Lord<lord@emf.net> wrote:
> > On Fri, 2009-07-31 at 20:11 +0000, Sylvain Galineau wrote:
> >
> >> If you look at the original submission, section 3.1 describes the header in question.
> >> (There is a typo though so replace 0x00010000 with 0x00020000). Notice the absence
> >> of rootstring space.
> >
> > The very fact that you have to replace the
> > version number is proof that the rootstring
> > space has not been eliminated but merely
> > compressed.   No future extension of EOTL
> > can reasonably use the 0x10000 version number
> > unless that future extension is EOT (sans
> > honoring root string restrictions).
> 
> Thomas, what are you *talking* about?  I am completely unable to get
> anything sensical out of this post.

EOTL is not "out of nowhere".  A reasonable
EOTL implementation, being "tolerant in what 
it receives", will process some EOT fonts.
Conversely, an unreasonable Recommendation would
require that implementations ensure that 
if a font file is EOT (not EOTL) that they
"MOST NOT" render it.  I am seeking clarification
that we are not steering towards a draft 
proposal of that unreasonable sort.

I believe in the sanctity of the standards
process.  I think that the concerns of current
implementers and other parties are secondary
to the logical structure and long term implications
of the standard.  I am seeking clarification on
these issues in the spirit of protecting that 
logical structure and long term view.

Aside from Sylvain's comments, I expected
and have so far seen that my goals are not
a problem for the other stake holders.  I 
wish to encourage making that more formally
explicit. I don't really have any clue what
Sylvain is doing, unless I draw quite unkind
conclusions about him.

-t


> 
> ~TJ

Received on Friday, 31 July 2009 22:57:10 UTC