- From: Jonathan Kew <jonathan@jfkew.plus.com>
- Date: Thu, 6 Aug 2009 22:29:43 +0100
- To: robert@ocallahan.org
- Cc: Sylvain Galineau <sylvaing@microsoft.com>, Tal Leming <tal@typesupply.com>, www-font <www-font@w3.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 UTC