It looks like some MS fonts report their kerning subtable lengths wrong. In one case, the length was reported to be some 19366, and yet the table also claimed to hold 14148 pairs (each pair consisting of 6 bytes). You do the math! We're going to assume that the microsoft fonts hold only a single kerning subtable, which occupies the entire length of the kerning table. Worst case, we lose any other subtables that the font contains, but it's better than reading a truncated kerning table. And what's more, it appears to work. So.
Or, at least, it makes it so all strings read from the file are automatically encoded as BINARY. Which does a lot for MY peace. It's even compatible between 1.8 and 1.9!
Specifically, always explicitly include glyph 0 in the subset at glyph index 0, and never assign characters to codes less than 32 (PDF doesn't, apparently, like that).
Just parse enough of each glyph to be able to write it back out in a font subset
This cleanup is a significant refactoring of the original ttfunk codebase. It removes the dependence on method_missing, and adds explicit attribute lists. It also avoids dynamic require statements, preferring to explicitly list the files to load. This cleanup also adds support for the 'loca', 'post', 'OS/2', and 'glyf' TrueType tables.