Re: [ft] Reading KERN subtables

[Werner LEMBERG]

> 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