W3C home > Mailing lists > Public > www-style@w3.org > June 2009

RE: New work on fonts at W3C

From: Levantovsky, Vladimir <Vladimir.Levantovsky@MonotypeImaging.com>
Date: Wed, 24 Jun 2009 15:22:00 -0400
Message-ID: <E955AA200CF46842B46F49B0BBB83FF2924E0D@wil-email-01.agfamonotype.org>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:19 GMT