RE: A way forward

> From: Håkon Wium Lie [mailto:howcome@opera.com]
> Sent: Friday, July 24, 2009 11:01 AM
> To: Sylvain Galineau
> Cc: Håkon Wium Lie; John Hudson; www-font
> Subject: RE: A way forward

> ZOT is different from EOTx though -- other browsers wouldn't have to
> replicate all the EOTx-related bugs and quirks.

Hakon, no one believes Opera or Mozilla would change their code to match IE's bugs
and quirks if we were to add support for raw font linking tomorrow without fixing them.
You would demand that IE fixes its implementation, as we should, and as we've done across
CSS2.1 and commit to keep doing in future releases across CSS and other web standards.

I therefore request that you refrain from insulting my intelligence - among others' - by
pretending otherwise. It's both strictly unnecessary and clearly ineffective.

Second, no one, to my knowledge, has stated that your browser should match IE's legacy behavior
or @font-face bugs REGARDLESS OF THE UNDERLYING FILE FORMAT WE ALL AGREE ON. You and John Daggett
are the only individuals making this conveniently ill-supported claim.

You are of course welcome to provide examples of 'EOTx-related bugs' you would have to replicate,
and explain why it would be necessary for you to do that work in the context of
the EOT-Lite proposal. The testcase you referenced earlier failed to make this
point rather spectacularly.

Ideally, you would be able to provide a real example i.e. by creating an EOT-Lite font
using Ascender's new tools and explain how and why you would not be able to skip over the
EMBEDDEDFONT prefix and treat the rest as a raw font, demonstrate it does not work in IE etc.

Again, that it may work differently in IE due to CSS parsing issues and other legacy
quirks is irrelevant as the same issues would exist regardless of the file format. ZOT would
not change anything.

To make sure we are on the same page, EOT-Lite means:
1. Raw font files are prefixed with a well-known binary header;
2. The user agent reads the parts of the header necessary to:
        a. Determine its length;
        b. Verify its validity e.g. ensure the rootstring field is null;
3. The user agent then proceeds to skip this header and treat the remainder of the resource as
it would a reference to its raw equivalent.

Now, which 'EOTx-related bugs' and other quirks are missing here which you'd have to match ?

>Here's a guess: not a single bug have been fixed in that code base for 10 years.
Your gratuitous guesses are as unlikely to prove your claim as your unproven assertions.

Received on Friday, 24 July 2009 18:42:15 UTC