OpenType CFF annotation and field appearances

The native appearance builders accept OpenType OTTO fonts with CFF 1 outlines as well as their existing TrueType input

Plain, rich, shaped, and family text appearances embed the full original OpenType file through FontFile3 with Subtype OpenType and a CIDFontType0 descendant

Name-keyed CFF uses glyph indices as CIDs, while CID-keyed CFF retains its actual Registry, Ordering, Supplement, and charset mapping from glyph indices to CIDs

The generated Encoding CMap maps text character codes to the actual CIDs; widths use those CIDs, ToUnicode retains logical text, and CIDFontType0 receives no CIDToGIDMap

Glyph positions and extents use HarfBuzz OpenType metrics, including rich fragment and combining-mark bounds; rich fragments share immutable per-style font readers and one embedded font resource

CFF metrics require a matching-architecture HarfBuzz library even when ShapeComplexText is False; HOTPDF_HARFBUZZ_LIBRARY selects an explicit path, and complex shaping additionally uses the existing FriBidi dependency

A visible FreeText annotation without a normal appearance can use a valid default-appearance resource containing a complete OpenType CFF font; the existing resource precedence, clipping, colors, and read-only embedding policy apply

Editable field generation still requires installable or editable permission; read-only fallback permits preview-and-print permission, while restricted or bitmap-only outlines remain rejected and no-subsetting retains every original font byte

Font-byte, glyph, object-size, aggregate rich-font, cancellation, and native render budgets remain enforced; malformed CFF INDEX offsets, dictionaries, charset ranges, duplicate CIDs, and missing collection strings are rejected before publication

The format mapping follows ISO 32000-1:2008 9.7.4.2 and 9.9, including the explicit CID-keyed OpenType charset mapping

Native rendering, MuPDF, and Ghostscript pass the sparse-CID OpenType fixtures; the tested Poppler backends have a separate sparse-CID OpenType mapping incompatibility, while Poppler identity-CID OpenType and sparse raw CIDFontType0C controls render correctly

Independent readers may synthesize a missing annotation appearance differently; explicit generated appearances are checked separately from each reader's fallback behavior

Missing annotation appearances can also retain original bare Type1, Type1C, and CIDFontType0C resources through the original raw-font annotation path; OpenType CFF2 input uses the separate static default-instance appearance backend with explicit format conversion, rather than embedding CFF2 directly in a PDF 1.7 font stream

See HPDFBuildHeadlessTextAppearance and TryGetCompactFontTable