Repository navigation
Improve TrueType spec compliance for generated font #123
Description
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
Activity
bsweeney commentedon Oct 15, 2023
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.
Do not map 0xFFFF in the cmap table
Set the head table checkSumAdjustment to zero
Re-calculate font header when generating TTF
bsweeney commentedon Oct 27, 2023
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:
Will revisit supporting platform 1 as needed since the platform uses legacy Macintosh text encodings:
Do not map 0xFFFF in the cmap table
Set the head table checkSumAdjustment to zero
Re-calculate font header when generating TTF
Do not map 0xFFFF in the cmap table
Set the head table checkSumAdjustment to zero
Re-calculate font header when generating TTF
bsweeney commentedon Dec 16, 2023
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
Add support for parsing cmap subtable format 2
Add support for parsing cmap subtable format 2
Do not map 0xFFFF in the cmap table
Set the head table checkSumAdjustment to zero
Re-calculate font header when generating TTF
Add support for parsing cmap subtable format 2
Do not map 0xFFFF in the cmap table
Set the head table checkSumAdjustment to zero
Re-calculate font header when generating TTF
Add support for parsing cmap subtable format 2