OpenType CFF-annotatie- en veldappearances

De native appearance-builders accepteren OpenType OTTO-fonts met CFF 1-outlines naast hun bestaande TrueType-invoer

Plain-, rich-, shaped- en family-text-appearances embedden het volledige oorspronkelijke OpenType-bestand via FontFile3 met Subtype OpenType en een CIDFontType0-descendant

Name-keyed CFF gebruikt glyph-indices als CIDs, terwijl CID-keyed CFF diens echte Registry, Ordering, Supplement en charset-mapping van glyph-indices naar CIDs behoudt

De gegenereerde Encoding CMap mapt tekstcharactercodes naar de echte CIDs; widths gebruiken die CIDs, ToUnicode behoudt logische tekst, en CIDFontType0 krijgt geen CIDToGIDMap

Glyph-posities en extents gebruiken HarfBuzz OpenType-metrics, inclusief rich-fragment- en combining-mark-bounds; rich-fragmenten delen immutable per-style font readers en één embedded font resource

CFF-metrics vragen een HarfBuzz-library met matchende architectuur, zelfs wanneer ShapeComplexText op False staat; HOTPDF_HARFBUZZ_LIBRARY selecteert een expliciet pad, en complex shaping gebruikt daarnaast de bestaande FriBidi-dependency

Een zichtbare FreeText-annotatie zonder normale appearance kan een geldige default-appearance-resource met een complete OpenType CFF-font gebruiken; de bestaande resource-precedence, clipping, kleuren en read-only embedding-policy gelden

Editable field-generatie blijft installable- of editable-permission vragen; read-only fallback staat preview-and-print-permission toe, terwijl restricted- of bitmap-only-outlines geweigerd blijven en no-subsetting elke oorspronkelijke fontbyte behoudt

Font-byte-, glyph-, object-size-, aggregate rich-font-, annulerings- en native render-budgetten blijven gehandhaafd; misvormde CFF INDEX-offsets, dictionaries, charset-ranges, dubbele CIDs en ontbrekende collection-strings worden geweigerd vóór publicatie

De format-mapping volgt ISO 32000-1:2008 9.7.4.2 en 9.9, inclusief de expliciete CID-keyed OpenType charset-mapping

Native rendering, MuPDF en Ghostscript halen de sparse-CID OpenType-fixtures; de geteste Poppler-backends hebben een aparte sparse-CID OpenType-mapping-incompatibiliteit, terwijl Poppler identity-CID OpenType en sparse raw CIDFontType0C-controls correct renderen

Onafhankelijke readers kunnen een ontbrekende annotation-appearance anders synthetiseren; expliciet gegenereerde appearances worden apart gecheckt ten opzichte van het fallback-gedrag van elke reader

Ontbrekende annotation-appearances kunnen ook oorspronkelijke bare Type1-, Type1C- en CIDFontType0C-resources behouden via het oorspronkelijke raw-font-annotatiepad; OpenType CFF2-invoer gebruikt de aparte static default-instance appearance backend met expliciete formaatconversie, in plaats van CFF2 rechtstreeks in een PDF 1.7-fontstream te embedden

Zie HPDFBuildHeadlessTextAppearance en TryGetCompactFontTable