W3C home > Mailing lists > Public > www-font@w3.org > July to September 2009

Re: WebOTF Proposal

From: Jonathan Kew <jonathan@jfkew.plus.com>
Date: Thu, 6 Aug 2009 22:29:43 +0100
Cc: Sylvain Galineau <sylvaing@microsoft.com>, Tal Leming <tal@typesupply.com>, www-font <www-font@w3.org>
Message-Id: <56F48CD0-C4DA-47AC-9B63-C890C7FC3316@jfkew.plus.com>
To: robert@ocallahan.org
On 6 Aug 2009, at 22:16, Robert O'Callahan wrote:

> On Fri, Aug 7, 2009 at 9:01 AM, Sylvain Galineau <sylvaing@microsoft.com 
> > wrote:
> Very nice !
>
> I have one outstanding question regarding ZOT compression: what are  
> the concrete benefits of per-table compression ? I'm willing to risk  
> a 'duh' answer here :) That's fine as I have no development  
> experience with low-level font handling.
>
> Being able to decompress just the CMAP would speed things up and  
> reduce memory usage if a downloaded font turns out to not support  
> the characters in your text. This could easily happen if content is  
> user-generated and you don't know what language it is.

Right. There are other possible scenarios, too, depending on how the  
client handles text. For example, skip decompressing the vertical  
metrics in a CJK font if you know you're doing horizontal layout (or  
vice versa). Skip the OpenType layout tables if your text engine  
doesn't support those features. Skip AAT tables if you're using an  
OpenType Layout engine, and vice versa.

The most simplistic use-case, of course, is to just reconstruct the  
complete OpenType font in memory, and proceed to use that, in which  
case it's essentially equivalent to compressing the entire font as a  
single block. But the per-table approach allows the client to optimize  
access based on its particular needs.

JK
Received on Thursday, 6 August 2009 21:30:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 11 June 2011 00:14:03 GMT