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