W3C home > Mailing lists > Public > www-font@w3.org > April to June 2009

hope for a way forward

From: Jonathan Kew <jonathan@jfkew.plus.com>
Date: Tue, 30 Jun 2009 23:50:34 +0100
Message-Id: <EF055CFA-1DC1-48CA-AFDC-263860583B2B@jfkew.plus.com>
To: www-font@w3.org
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  

Jonathan Kew
Received on Tuesday, 30 June 2009 22:51:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:31 UTC