RE: New work on fonts at W3C

On Wednesday, June 24, 2009 12:53 PM Thomas Lord wrote:
> 
> Vlad,
> 
> I understand you to advocate for either or both:
> 
> a) "XORing a few bits" in an existing font
> 
> b) Applying compression in an ad-hoc, novel way
>    with little or know advantage over whole-file
>    gzip other than "obscurity"
> 

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. 

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

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 17:28:25 UTC