RE: New work on fonts at W3C

On Wednesday, June 24, 2009 4:40 PM Thomas Lord wrote:
> 
> On Wed, 2009-06-24 at 15:22 -0400, Levantovsky, Vladimir wrote:
> 
> I'm sorry to be slightly confrontational on that
> point but I don't think you have explained why
> the quoted paragraph says:
> 
>    (If gzip is applied to the whole file, it is
>    likely to be unzipped automatically at the HTTP
>    level.)
> 
> I think that that sentence says, in plain English, that
> the goal is for a compression scheme that breaks existing
> interoperability!
> 

I don't see how the goal for compression could be to break existing
interoperability.

> 
> > 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.
> 
> There's been huge progress that I've seen and,
> although we're having our differences here
> I can't stress enough how much I appreciate and
> respect so much of what you and Monotype Imaging
> have been saying.
> 

Thank you.

> 
> >
> > 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.
> 
> 
> I think (but am not sure yet) that I was, indeed, confused
> about CATT.   Can any conforming TT engine render CATT fonts
> or only some?  Can a free software TT engine be improved to
> render CATT fonts (if can't already) without running into
> any legal problems?
> 

Any conformant TrueType/OpenType engine should be able to render CATT
fonts.

> In any event, the way in which I was not confused about
> CATT is that that form of making fonts smaller seems much
> more important to me than a few percentage points here and
> there between different compression schemes.
> 

The use of composite glyphs is purely a design issue, CATT employs a
design methodology that has nothing to do with compression. Some
character sets like CJK have many identical or similar contours and are
much better suitable for compositing, other character sets may require a
unique representation for every glyph and may not at all be suitable for
use of composites.

Since CATT (which stands for Compact Asian TrueType, btw) are 100%
standard-compliant TrueType fonts - they can be compressed with MTX the
same way as any other fonts.

> I remain unclear why MTX is *important* when there are
> more standard techniques already available.
> 

In addition to achieving better compression efficiency, MTX compressor
splits font data in separate, individually compressed data blocks. This
can allow, for example, implementing a font streaming / progressive
rendering, where font metrics and layout tables can be downloaded,
decompressed and used for page layout and composition while the glyph
data and hints instructions are being downloaded. Not only it will speed
up page loading because of superior compression results, but it'd also
allow to render a page faster.

> As I asked before: can you quantify how much better MTX
> is than, say, a sane use of bzip2 or gzip in some way
> that others can verify it?   Numbers seem to be missing in the
> W3C discussion around this.
> 

Using gzip (best compression option) and WEFT (no subsetting) - the
following are the results (in KB):
   Font     |   raw size   |   gzip   |   WEFT
Times NR    |      316     |   181    |   142
Arial       |      267     |   148    |   113
Georgia     |      140     |    90    |    67
Verdana     |      137     |    81    |    59

As you can see, gzip produces file sizes that are on average 30-35%
larger than WEFT (the WEFT size also includes the EOT header).

Regards,
Vladimir

> -t
> 
> 
> >
> > 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 Thursday, 25 June 2009 02:12:46 UTC