RE: hope for a way forward

With all due respect, I said nothing about non-standard compression, any
compression would be better than none. Since LZMA is proven to do such a
good job - I am fine with using it "as is" (or any other compression for
that matter).

Regards,
Vladimir


> -----Original Message-----
> From: www-font-request@w3.org [mailto:www-font-request@w3.org] On
> Behalf Of Thomas Lord
> Sent: Tuesday, June 30, 2009 9:39 PM
> To: Jonathan Kew
> Cc: www-font@w3.org
> Subject: Re: hope for a way forward
> 
> You have snuck in a requirement to use non-standard
> compression for the sole purpose of introducing incompatibility
> and in that way have made a proposal that you yourself
> should recognize "will be perceived negatively".
> 
> You haven't (and probably can't) show the "technical
> benefit" of using a non-standard compression scheme, or
> at least you can't show a convincing enough advantage to it.
> 
> -t
> 
> 
> 
> 
> On Tue, 2009-06-30 at 23:50 +0100, Jonathan Kew wrote:
> > Having watched the web-fonts debate for a while now, I'd like to
take
> > a fresh shot at presenting a way forward that I hope (in my naivety)
> > might be acceptable to the various parties involved. There's nothing
> > really new here, but as I've tried to listen to the various
> viewpoints
> > and concerns, it seems to me that we should be able to find some
> > common ground.
> >
> > Given that:
> >
> > * major foundries are justifiably concerned about the use of "raw"
> TTF
> > and OTF as web font formats, because this is perceived as making
> > license violations - even inadvertent ones - too easy;
> >
> > * defining a new format whose main purpose appears to be to hinder
> > font interoperability between browsers and desktop operating systems
> > may be perceived negatively; and
> >
> > * a "wrapper" such as EOT serves no essential purpose if root-string
> > restrictions (or equivalent) are not used, as TTF/OTF fonts already
> > provide a standard means to include informative licensing metadata
> > that could be presented to users if desired;
> >
> > I find it difficult to be enthusiastic about simple "obfuscation" or
> > about a "font wrapper" that merely encapsulates the font file in
some
> > additional metadata.
> >
> > Further, given that:
> >
> > * typical font data is quite compressible, and using a compressed
> > format could provide significant benefits to users (and especially
to
> > users with low-bandwidth connections/devices);
> >
> > * applying standard "whole-file" compression such as gzip does not
> > address the foundries' concerns, because linked fonts would be
> > trivially (quite likely even transparently) decompressed on
> > downloading; and
> >
> > * a compression scheme designed specifically for fonts could offer
> > tangible benefits, which might include better compression and/or
more
> > efficient access to the data;
> >
> > I'd like to suggest that a solution is to adopt a compressed-font
> > format as the recommended standard for web fonts. Such a format
would
> > be designed specifically for use with TrueType and OpenType fonts,
> > free of any licensing or patent limitations, and simple for browser
> > vendors to incorporate. Browsers would be expected to implement
> > default same-origin restrictions for such fonts, so that cross-site
> > linking will not work unless the site hosting the font specifically
> > chooses to allow it (having checked that the font license permits
> > this, of course, and having decided that the potential bandwidth use
> > is acceptable).
> >
> > If we expect (or hope) that the use ohttp://lambda-the-
> ultimate.org/trackerf linked fonts will become
> > widespread on the web, applying compression to all that data is
> > beneficial to everyone. And it should not seem strange if there is a
> > font-specific approach to compression; just as distinct compression
> > techniques have been designed for graphics, video, and audio, a
> > technique designed for font data makes sense.
> >
> > While it is true that using a compressed-font format will
> > differentiate web fonts from desktop fonts, preventing "drag and
> drop"
> > installation on current operating systems, it is important to note
> > that what I am suggesting is not "obfuscation", rather it is
> > compression for the sake of more efficient transmission.
> >
> > For the foundries that are concerned about "raw" TTF/OTF fonts being
> > deployed on web servers, it provides the same benefit as obfuscation
> > proposals - but with a positive technical benefit instead of the
> > negative image that obfuscation carries in some quarters.
> >
> > For browser vendors, the aim is to have a format that all - both
> > proprietary and free/open - can agree to implement without
> > compromising either principles or commercial interests, and that can
> > be implemented with minimal effort and extra code.
> >
> > Being simply a compressed form of the existing font files, carrying
> > exactly the same information, it cannot be perceived as even a
> > potential vehicle for any form of DRM, any more than the license
> field
> > or the embedding bits already present in the fonts.
> >
> > What might such a compressed font format look like? A few days ago,
I
> > was on the verge of writing a message specifically proposing the
> > adoption of "unwrapped" (non-EOT) MTX, with extensions to support
> > OpenType/CFF, as the recommended web font format. However, I've been
> > having second thoughts about this, and have an alternative approach
> to
> > suggest that I believe would offer some technical benefits. But I
> will
> > save that for a separate message.
> >
> > Of course, I don't expect that IE will drop support for EOT, but I'd
> > like to think that Microsoft would be willing to add support for
> same-
> > origin/CORS-controlled compressed fonts if foundries indicate their
> > readiness to license fonts on this basis. And similarly, I don't
> > expect the other browser vendors to remove their current support for
> > TTF/OTF, which offers the simplest route for authors (using the
exact
> > same font files on the desktop and the web server) in cases where
> > licenses permit it. But perhaps all parties could agree to also
> > support a common compressed format - and vendors agree to license
> > fonts for deployment in this format - so that in due course authors
> > will have the option of serving a single compact font for use by all
> > browsers.
> >
> > Jonathan Kew
> >
> >
>

Received on Wednesday, 1 July 2009 01:43:35 UTC