Skip to content

Improve TrueType spec compliance for generated font #123

Open
@bsweeney

Description

@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
  • 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
      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

bsweeney commented on Oct 15, 2023

@bsweeney
MemberAuthor

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

bsweeney commented on Oct 27, 2023

@bsweeney
MemberAuthor

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

bsweeney commented on Dec 16, 2023

@bsweeney
MemberAuthor

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

9 remaining items

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      Improve TrueType spec compliance for generated font · Issue #123 · dompdf/php-font-lib