RE: EOT-Lite File Format

On Friday, July 31, 2009 3:08 AM John Daggett wrote:
> 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.

I agree with your conclusions but for the sake of clarification only - the largest chunk of MTX complexity lies in the compressor, implementing decompressor is rather straightforward. If MTX is adopted, Monotype is likely to release the code (and the spec already gives you all the essential chunks), so that UA vendors would not need to re-invent it, they would simply integrate the existing implementation.

> 
> 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.
> 

I believe the web authors do not always have control over server configurations, so the fact that browsers *can* apply gzip doesn't automatically translates that it *will* be the case for fonts.

Regards,
Vlad

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