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:39:35 UTC