Re: hope for a way forward

On 1 Jul 2009, at 02:38, Thomas Lord wrote:

> 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 have made your view on this quite clear already (which is partly  
why I commented on this aspect in the original message); I disagree  
with your perception. The purpose of the proposed compression is not  
to create incompatibility but to improve efficiency (of web transport,  
in particular). The fact that it would also address foundries'  
concerns about deploying "raw" fonts in today's desktop formats is of  
course a valuable side benefit.

As for "introducing incompatibility", applying a targeted compression  
method will not do this any more than packaging a standard font in  
some additional "wrapper" that provides no actual technical benefit;  
it may contain metadata such as copyright and licensing information,  
but fonts already provide a means to include this. Either the wrapper  
can be automatically generated by a tool (equivalent to applying a  
simple compression tool), in which case it adds no value; or else it  
requires additional information that is not available from the  
original font, in which case creating it will be a burden on authors.

> 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.

I will be writing more about a possible approach to font compression,  
but in brief, what I will suggest is an approach that compresses  
individual font tables rather than the file as a whole. The key  
advantage of this is that the user agent can then access a particular  
table (e.g., the cmap, to check character coverage) without having to  
decompress the entire font. In resource-constrained environments such  
as small mobile devices, this could be a significant benefit.

JK

Received on Wednesday, 1 July 2009 08:58:27 UTC