Improve TrueType spec compliance for generated font

[bsweeney]

When generating a new font file this library currently writes out a significant number of font table data using the values specified in the original font file. The resulting font may have values that do not conform to expectations per the spec because a number of those values are dependent on the font structure, supported characters, and related glyphs.

This is a tracking issue to help identify and track these issues.

• global table issues
  • Table misalignment (Subset fails: OTS parsing error: hhea: misaligned table #119)
• font header
  • Font header invalidated by modification of the number of tables in the font
  • Table checksum does not match expectations
  • Tables in the directory are not sorted by tag.
• head table
  • subsetting invalidates the font checksum
• name table
  • Correctly handle string encoding (Why use UTF16ToUTF8() ? #70)
• cmap table
  • Unicode 0xFFFF (65535) should be present but not mapped
  • Improve character encoding support
  • improve error handling (Improve cmap table (subtable format 4) error handling #127)
  • add support for subtable format 0
  • add support for subtable format 2
  • add support for subtable format 6
  • add support for subtable format 8
  • add support for subtable format 10
  • add support for subtable format 13
  • add support for subtable format 14

[bsweeney]

Regarding table order in the directory, per the spec entries in the table directory must be sorted in ascending order by tag.
https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6.html

However, some tables depend on data from other tables having been encoded. Perhaps to address this issue we can write all table data, then write the sorted table directory entries.

[bsweeney]

I'm looking at improving string encoding support but deeper analysis will need to be done to determine the full extent of scenarios need to be handled.

Of special note, support for platform 1 is being deferred for now. Primarily because the spec discourages use of this platform:

Names with platformID 1 were required by earlier versions of macOS. Its use on modern platforms is discouraged. Use names with platformID 3 instead for maximum compatibility. Some legacy software, however, may still require names with platformID 1, platformSpecificID 0.

Will revisit supporting platform 1 as needed since the platform uses legacy Macintosh text encodings:

Strings for the Macintosh platform (platform ID 1) use platform-specific single- or double-byte encodings according to the specified encoding ID for a given name record.

[bsweeney]

Might be useful to support encoding conversion (e.g., Big5 to Unicode). Some internal processes rely on a Unicode cmap. Notably, the library writes out the cmap table hard coded to platform ID 3, platform specific ID 1. So without a Unicode map writing the font will fail.

Unicode provides a collection of conversion tables:
https://github.com/unicode-org/icu-data/blob/main/charset/data/ucm