RE: EOT-Lite File Format

Friday, July 31, 2009 John Daggett <jdaggett@mozilla.com>:

>Adding MTX to a format adds significant complexity.  From a
>implementor's perspective it's "new code", it needs to be tested and
>the relative complexity of the code means creating conformance
>criteria should not be underestimated.  If you add MTX, 90% of the
>code to support EOT-Lite will be in MTX.  It greatly increases the
>probability that the output of EOT-Lite tools won't always match what
>a given browser expects.  Ten years with one tool outputting (WEFT)
>and one library to consume it (t2embed) does not compare to a
>situation where there are n tools to output it and m libraries to
>consume it.

>As I've said before, browsers already have code to do gzip decompression
>so you need to justify why adding MTX is significantly better than straight
>gzip compression, since the implementation of that has already been done
>and is stable code in all user agents.  The logic behind "a font format 
>should be compressed therefore we need MTX" is oversimplified.

Noted. Time is of the greatest importance here.

Regards,

rich



-----Original Message-----
From: www-font-request@w3.org [mailto:www-font-request@w3.org] On Behalf Of John Daggett
Sent: Friday, July 31, 2009 3:08 AM
To: www-font
Subject: Re: EOT-Lite File Format

Thursday, July 30, 2009 Vladimir Levantovsky
<Vladimir.Levantovsky@MonotypeImaging.com>:

> >Monotype would be very supportive if MTX compression is included as part
> >of EOT-Lite Recommendation. Our offer and our commitment remains the
> >same - we will provide unrestricted royalty-free patent license if MTX
> >is included in the deal.
> 
> If memory serves me correctly, John Daggett voiced a concern about the
> amount of time additional testing, evaluation, etc... of MTX would entail.
> Time *is* of great concern, but I'm wondering if John has had any new
> thoughts on the matter.
> There's a broad consensus that the next generation web font format
> beyond EOT should feature compression. And therefore I think that,
> looking back, there might be regrets at not having incorporated MTX
> royalty free when there was the chance. Fonts are big files.
> Compression has benefits. Is EOTL, the improvement to EOT, to be
> inferior to EOT in this regard? Looked at in this way, it doesn't
> make a lot of sense. MTX has been working code in IE for what, ten
> years? I, too, urge that we give the pros, cons, and practicalities
> of incorporating MTX a last going-over.

Adding MTX to a format adds significant complexity.  From a
implementor's perspective it's "new code", it needs to be tested and
the relative complexity of the code means creating conformance
criteria should not be underestimated.  If you add MTX, 90% of the
code to support EOT-Lite will be in MTX.  It greatly increases the
probability that the output of EOT-Lite tools won't always match what
a given browser expects.  Ten years with one tool outputting (WEFT)
and one library to consume it (t2embed) does not compare to a
situation where there are n tools to output it and m libraries to
consume it.

As I've said before, browsers already have code to do gzip decompression
so you need to justify why adding MTX is significantly better than straight
gzip compression, since the implementation of that has already been done
and is stable code in all user agents.  The logic behind "a font format 
should be compressed therefore we need MTX" is oversimplified.

Received on Friday, 31 July 2009 16:04:18 UTC