Appearance di annotazioni e campi OpenType CFF
I builder di appearance nativi accettano font OpenType OTTO con contorni CFF 1 oltre al loro input TrueType esistente
Le appearance di testo plain, rich, shaped e family incorporano il file OpenType originale completo tramite FontFile3 con Subtype OpenType e un discendente CIDFontType0
Il CFF con chiave per nome usa gli indici dei glifi come CID, mentre il CFF con chiave CID conserva il suo Registry, Ordering, Supplement e mapping charset effettivi dagli indici dei glifi ai CID
Il Encoding CMap generato mappa i codici carattere del testo ai CID effettivi; i width usano quei CID, ToUnicode conserva il testo logico e CIDFontType0 non riceve CIDToGIDMap
Posizioni ed estensioni dei glifi usano le metriche OpenType di HarfBuzz, inclusi i limiti dei fragment rich e dei segni combinanti; i fragment rich condividono reader di font immutabili per stile e una sola risorsa di font incorporata
Le metriche CFF richiedono una libreria HarfBuzz di architettura corrispondente anche quando ShapeComplexText è False; HOTPDF_HARFBUZZ_LIBRARY seleziona un percorso esplicito, e lo shaping complesso usa inoltre la dipendenza FriBidi esistente
Un'annotazione FreeText visibile senza appearance normal può usare una risorsa di appearance predefinita valida contenente un font OpenType CFF completo; si applicano la precedenza delle risorse, il clipping, i colori e la politica di incorporamento read-only esistenti
La generazione di campi modificabili richiede ancora il permesso installable o editable; il fallback read-only consente il permesso preview-and-print, mentre i contorni restricted o bitmap-only restano rifiutati e no-subsetting conserva ogni byte del font originale
I budget di byte del font, glifi, dimensione oggetto, font rich aggregato, cancellazione e render nativo restano applicati; offset INDEX CFF malformed, dizionari, intervalli di charset, CID duplicati e stringhe di collezione mancanti vengono rifiutati prima della pubblicazione
Il mapping di formato segue ISO 32000-1:2008 9.7.4.2 e 9.9, incluso il mapping charset esplicito di OpenType con chiave CID
Rendering nativo, MuPDF e Ghostscript passano i fixture OpenType sparse-CID; i backend Poppler testati hanno un'incompatibilità separata di mapping OpenType sparse-CID, mentre i controlli Poppler OpenType identity-CID e CIDFontType0C raw sparse renderizzano correttamente
Lettori indipendenti possono sintetizzare un'appearance di annotazione mancante in modo diverso; le appearance generate esplicite vengono verificate separatamente dal comportamento di fallback di ciascun reader
Le appearance di annotazione mancanti possono anche conservare risorse Type1, Type1C e CIDFontType0C bare originali tramite il percorso di annotazioni raw-font originale; l'input OpenType CFF2 usa il backend di appearance dell'istanza predefinita statica separato con conversione di formato esplicita, invece di incorporare CFF2 direttamente in uno stream di font PDF 1.7
Vedere HPDFBuildHeadlessTextAppearance e TryGetCompactFontTable