RE: hope for a way forward

On Tue, 2009-06-30 at 21:43 -0400, Levantovsky, Vladimir wrote:
> With all due respect, I said nothing about non-standard compression,


My overly-defensive misunderstanding, then.
My apologies.

Regards,
-t




>  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 02:06:35 UTC