OpenType-CFF-Annotations- und Feld-Appearances

Die nativen Appearance-Builder akzeptieren OpenType-OTTO-Fonts mit CFF-1-Outlines genauso wie deren bestehende TrueType-Eingaben

Plain-, Rich-, Shaped- und Family-Text-Appearances betten die vollständige originale OpenType-Datei über FontFile3 mit Subtype OpenType und einen CIDFontType0-Nachfahren ein

Name-keyed CFF nutzt Glyph-Indizes als CIDs, während CID-keyed CFF seine tatsächliche Registry-, Ordering- und Supplement-Zuordnung samt Charset-Mapping von Glyph-Indizes zu CIDs beibehält

Die erzeugte Encoding-CMap mappt Text-Zeichencodes auf die tatsächlichen CIDs; die Widths nutzen diese CIDs, ToUnicode behält den logischen Text, und CIDFontType0 erhält keine CIDToGIDMap

Glyph-Positionen und -Extents nutzen HarfBuzz-OpenType-Metriken, einschließlich Rich-Fragment- und Combining-Mark-Bounds; Rich-Fragmente teilen sich unveränderliche per-Style-Font-Reader und eine eingebettete Font-Ressource

CFF-Metriken verlangen eine HarfBuzz-Bibliothek mit passender Architektur, selbst wenn ShapeComplexText False ist; HOTPDF_HARFBUZZ_LIBRARY wählt einen expliziten Pfad, und komplexes Shaping nutzt zusätzlich die bestehende FriBidi-Abhängigkeit

Eine sichtbare FreeText-Annotation ohne normale Appearance kann eine gültige Default-Appearance-Ressource mit einem vollständigen OpenType-CFF-Font verwenden; die bestehende Ressourcen-Präzedenz, Clippping, Farben und die Read-only-Embedding-Policy gelten unverändert

Die erzeugbare editierbare Feldgenerierung verlangt weiterhin Installable- oder Editable-Rechte; der schreibgeschützte Fallback erlaubt Preview-and-Print-Rechte, während Restricted- oder Bitmap-only-Outlines abgelehnt bleiben und No-Subsetting jedes Original-Font-Byte behält

Font-Byte-, Glyph-, Objektgrößen-, Rich-Font-Aggregat-, Abbruch- und native Render-Budgets bleiben durchgesetzt; fehlerhafte CFF-INDEX-Offsets, Dictionaries, Charset-Bereiche, doppelte CIDs und fehlende Collection-Strings werden vor der Veröffentlichung abgelehnt

Das Format-Mapping folgt ISO 32000-1:2008 9.7.4.2 und 9.9, einschließlich des expliziten CID-keyed-OpenType-Charset-Mappings

Natives Rendering, MuPDF und Ghostscript bestehen die Sparse-CID-OpenType-Fixtures; die getesteten Poppler-Backends haben eine separate Inkompatibilität beim Sparse-CID-OpenType-Mapping, während Poppler mit Identity-CID-OpenType und Sparse-Raw-CIDFontType0C-Kontrollen korrekt rendert

Unabhängige Reader können eine fehlende Annotation-Appearance anders synthetisieren; explizit erzeugte Appearances werden getrennt vom Fallback-Verhalten jedes Readers geprüft

Fehlende Annotation-Appearances können auch originale bare-Type1-, Type1C- und CIDFontType0C-Ressourcen über den ursprünglichen Raw-Font-Annotations-Pfad behalten; OpenType-CFF2-Eingaben nutzen das separate statische Default-Instance-Appearance-Backend mit expliziter Formatkonvertierung, statt CFF2 direkt in einen PDF-1.7-Font-Stream einzubetten

Siehe HPDFBuildHeadlessTextAppearance und TryGetCompactFontTable