[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft] Reading KERN subtables
From: |
Werner LEMBERG |
Subject: |
Re: [ft] Reading KERN subtables |
Date: |
Thu, 22 Aug 2013 09:22:00 +0200 (CEST) |
> For a couple of my projects, I need to retrieve a list of all
> kerning pairs defined in the KERN table (subtable format 0). (I'm
> populating externally-defined API data structures which require it.)
Sounds very inefficient.
> If anyone knows where I can find a sample of such a (TrueType) font,
> I'd appreciate it. (That's question #1.)
Given that it essentially affects old Apple fonts only you probably
might ignore format 2 completely. Modern fonts don't have `kern' (or
probably just a rudimentary version covering the most basic needs) but
`GPOS'. However, in case you find one I would like to have it
also :-)
> However, I found something odd when examining the font 'Constantia
> Regular' (CONSTAN.TTF) v5.90. It shows a single kerning subtable,
> format 0, with 36740 kerning pairs. But each pair occupies 6 bytes,
> meaning the total subtable size is over 200KB -- much too large for
> the unsigned short 'length' field in the subtable header. Indeed,
> the 'length' field shows a value of around 23KB, which is obviously
> bogus. So my second question is, what is the correct way of coping
> with this scenario? (And is this a buggy font, or have I made a
> mistake somewhere?)
Having such a large table is indeed against the specification.
However, it *might* work, depending on the strictness of the
implementation: If there is only a single subtable, the actual value
of the `length' field is basically unimportant. Of course, the right
solution is to split into a set of smaller subtables.
> Finally, looking at how the old ftxkern extension did this, it appears very
> strange to me. It defines
> TT_Kern_Subtable* tables;
> in the kerning directory. It then seemingly treats 'tables' as an array of
> fixed-size elements, e.g.:
> TT_Kern_Subtable* sub;
> ...
> sub = kern->tables + kern_index;
> where kern_index is the desired subtable number. How can this
> possibly work? If I read the OTF spec correctly, each subtable may
> be a different length - containing not only a variable-format
> header, but the kerning data itself, which is of arbitrary size. Am
> I just obtuse, or missing something?
Sorry, I have no time to check this old code. The best solution IMHO
is to merge kerning subtables back into a single kerning table.
Werner