RE: hope for a way forward

Thank you, Jonathan

Monotype would support this proposal and would work together with
browser vendors to find a suitable solution.

Best regards,
Vladimir


> -----Original Message-----
> From: www-font-request@w3.org [mailto:www-font-request@w3.org] On
> Behalf Of Jonathan Kew
> Sent: Tuesday, June 30, 2009 6:51 PM
> To: www-font@w3.org
> Subject: hope for a way forward
> 
> 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 of 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:26:40 UTC