- From: Levantovsky, Vladimir <Vladimir.Levantovsky@MonotypeImaging.com>
- Date: Wed, 24 Jun 2009 15:22:00 -0400
- To: "Thomas Lord" <lord@emf.net>
- Cc: "Aryeh Gregor" <Simetrical+w3c@gmail.com>, "Brad Kemper" <brad.kemper@gmail.com>, "Jonathan Kew" <jonathan@jfkew.plus.com>, <www-style@w3.org>
On Wednesday, June 24, 2009 2:35 PM Thomas Lord wrote: > > The reason I have these questions about the > appropriateness of MTX is because this: > > http://lists.w3.org/Archives/Public/www-style/2008Nov/0412.html > > says this: > > [Compression] could be MTX, but it currently seems > safer to reuse gzip. The compression would be applied > selectively to chunks inside the file. (If gzip is > applied to the whole file, it is likely to be unzipped > automatically at the HTTP level.) > > which suggests the goal of choosing a compression > technique based not its merits but rather on what > interoperability it will break. > Quite the opposite - I believe the concern was that even though the MTX compression produces better results, its use may be hindered by other, non-technical issues such as patent licensing. Well, a lot of things changed since November last year, with MTX offered under GPL-compatible license being one of them. What seemed to be a "show-stopper" is no longer the case. > I additionally have skepticism about MTX because > of the existence of CATT. > Both TrueType and OpenType fonts support simple and composite glyphs (http://www.microsoft.com/typography/otspec/glyf.htm). CATT has nothing to do with compression, it's just a smarter way of designing a font (where each complex glyph is designed to take advantage of the similarities between individual radicals that comprise a complex ideograph in CJK languages), and then utilize composite glyph description to re-use those radicals. From the user or font engine point of view - CATT is just a regular TrueType/OpenType font. CATT and MTX have nothing in common. Hope this explanation helps. Regards, Vladimir > > > On Wed, 2009-06-24 at 13:27 -0400, Levantovsky, Vladimir wrote: > > > First of all, to make things clear, MTX compression gives you a > > significant advantage in compression efficiency comparing to generic > > whole-file gzip. And, since MTX compression is offered on GPL- > compatible > > terms, there is no "obscurity" either - anyone will be free to use it > > any way you like. > > > From the compression efficiency point of view - it is known that > > exploiting the known redundancies of the target object will yield you > > much better compression results. This is true for audio (mp3), still > > image (jpeg) and video (h.264) - this is also true for fonts. MTX > does > > exactly that. > > It sounds plausible to me that MTX compression results > in an important level of file size savings compared to > bzip2 or gzip with blocking or some other already > open and standard technique that can support a degree > of random access. > > It also sounds plausible that the opposite is true: that > MTX might do a bit better than a generic technique but > not enough better to be of much concern. Monotype > customers who buy MTX technology get plenty of other > advantages in terms of software libraries and support: > I'm not knocking the product. I'm questioning > whether the product is appropriate in this W3C context. > > Two contradictory possibilities both sounding plausible, > I guess I am left feeling skeptical. > > Can you quantify things in a way others can double > check? I couldn't find numbers in the W3C discussion > or on Monotypes web site. > > Also, is Monotype additionally offering the "Compact Asian Tech. > for TrueType"? That is where I would expect pretty > huge savings although, to be sure, it's harder to implement. > I haven't seen it discussed here yet it would seem to be > relevant to the problems at hand. > > The question about obfuscation / obscurity here is not > whether or not MTX is unknown but rather whether or not > there is a good reason to use it. > > > > > Monotype made an offer to contribute this technology for the web, and > I > > see no contradiction in using the technology to compress a specific > type > > of payload (font) in a generic wrapper format you propose to adopt - > > these two technology simply complement each other. > > Perhaps. > > > > I believe we both > > agree that compression is always a benefit, and having a compressed > font > > file will speed up the page download and processing. If W3C and > browser > > vendors adopt the MTX technology, they will be pioneers in > implementing > > a solution that may enjoy wide-spread use in the future. > > Is it your position that a web font Recommendation > would reasonably: > > 1) require direct linking of OT > 2) require direct linking of TT > 3) require direct linking of MTX-compressed TT? > > -t > > > > > > > > > Regards, > > Vlad > > > > > > > > The rationale for this kind of "obfuscation" > > > is apparently to break interoperability among > > > application programs. Web UAs are supposed to > > > use the new format, other programs, not. > > > > > > It would be wrong for a W3C Recommendation to > > > be constructed upon the rationale of breaking > > > interoperability among other programs. That is > > > why I suggested this is an issue for TAG: the > > > direction you are suggesting is contrary to the broad > > > architectural goals of Web Recommendations. > > > > > > Furthermore, free software programs that read or > > > write fonts are likely to eventually adopt the > > > "obscure" format as native. While Acme Foundry Ltd. > > > may not want their fonts drag-n-dropped from the > > > web to the desktop, Libre Fonts Inc. surely does. > > > > > > The net result is a gratuitous proliferation > > > of font formats and new obstacles to document exchange > > > between free software users and other users. > > > > > > My idea, a media-type-independent wrapper for conveying > > > human-friendly meta-data with any media file, avoids > > > these problems. > > > > > > It's rationale is to introduce a format capable of > > > conveying licensing information with every font. > > > That is, the goal is a new feature for users. > > > > > > There would be no a priori need for any program that > > > reads or writes fonts to not adopt the wrapper format > > > as a native format. Vendors of software used for web > > > authoring are free to implement features which help > > > users pay attention to the meta-data. > > > > > > With the wrapper as I proposed it, suppliers of > > > restricted-license fonts could still declare that no > > > use of those fonts in the old raw format is permitted - > > > that license information must always be wrapped around > > > those. > > > > > > Initially, no wrapped font could be casually > > > drag-n-dropped from web to desktop: legacy > > > programs won't recognize the new format. > > > > > > Eventually, fonts could be drag-n-dropped but > > > only as application programs learn to recognize the > > > wrapper and assist users with the (presumably > > > license-specifying) meta-data. > > > > > > Do you see the difference? > > > > > > Your proposals are rationalized as a way > > > to break some forms of interoperability. > > > > > > My proposal is rationalized as a way to add > > > useful functionality. > > > > > > Both proposals achieve the major goals of the > > > vendors of restricted license fonts. > > > > > > -t > > > > >
Received on Wednesday, 24 June 2009 19:22:36 UTC