RE: hope for a way forward

My apologies to all on this list for a possible confusion - I thought I
was making a clarification for a "wrapped(compressed(X))" proposal and
didn't realize that I was replying to a different thread.

Anyway, I want to say once again that:
- I believe that compression does provide a significant tangible
benefit, and an efficient compression that is also free to use is a very
desirable tool.
- I do like what Thomas has proposed. I see a lot of value in having a
generic wrapper format with compressed payload, and with everything else
being equal (i.e. if browser vendors do not have a strong preference for
implementing one or another) I would give my vote to
"wrapped(compressed(X))"

Cheers,
Vladimir


> -----Original Message-----
> From: www-font-request@w3.org [mailto:www-font-request@w3.org] On
> Behalf Of Levantovsky, Vladimir
> Sent: Tuesday, June 30, 2009 9:43 PM
> To: Thomas Lord; Jonathan Kew
> Cc: www-font@w3.org
> Subject: 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:59:43 UTC