Apparences d'annotations et de champs OpenType CFF

Les builders natifs d'apparences acceptent les polices OpenType OTTO à outlines CFF 1 en plus de leurs entrées TrueType existantes

Les apparences de texte plain, rich, shaped et family embarquent le fichier OpenType d'origine complet via FontFile3 avec le Subtype OpenType et un descendant CIDFontType0

Le CFF name-keyed utilise les indices de glyphes comme CIDs, tandis que le CFF CID-keyed conserve son triplet Registry, Ordering, Supplement réel et son mapping charset des indices de glyphes vers les CIDs

La CMap d'encoding générée mappe les codes de caractères du texte vers les CIDs réels ; les widths utilisent ces CIDs, ToUnicode conserve le texte logique, et CIDFontType0 ne reçoit aucune CIDToGIDMap

Les positions et extents de glyphes emploient les métriques OpenType de HarfBuzz, bornes des fragments riches et des marques combinantes comprises ; les fragments riches partagent des lecteurs de police immuables par style et une seule ressource de police embarquée

Les métriques CFF exigent une bibliothèque HarfBuzz d'architecture correspondante même quand ShapeComplexText vaut False ; HOTPDF_HARFBUZZ_LIBRARY sélectionne un chemin explicite, et le shaping complexe exploite en plus la dépendance FriBidi existante

Une annotation FreeText visible sans apparence normale peut utiliser une ressource d'apparence par défaut valide contenant une police OpenType CFF complète ; la précédence de ressources existante, le clipping, les couleurs et la politique d'embarquement en lecture seule s'appliquent

La génération de champs éditables exige toujours une permission installable ou editable ; le repli en lecture seule tolère la permission preview-and-print, tandis que les outlines restricted ou bitmap-only restent refusées et le no-subsetting conserve chaque octet de police d'origine

Les budgets d'octets de police, de glyphes, de taille d'objet, d'agrégat de police riche, d'annulation et de rendu natif restent appliqués ; offsets CFF INDEX mal formés, dictionnaires, plages de charset, CIDs dupliqués et chaînes de collection manquantes sont rejetés avant publication

Le mapping de format suit l'ISO 32000-1:2008 9.7.4.2 et 9.9, mapping charset OpenType CID-keyed explicite compris

Le rendu natif, MuPDF et Ghostscript passent les fixtures OpenType sparse-CID ; les backends Poppler testés ont une incompatibilité distincte de mapping OpenType sparse-CID, tandis que Poppler rend correctement les contrôles OpenType identity-CID et CIDFontType0C bruts sparse

Des lecteurs indépendants peuvent synthétiser une apparence d'annotation manquante différemment ; les apparences générées explicites sont contrôlées séparément du comportement de repli de chaque lecteur

Les apparences d'annotation manquantes peuvent aussi conserver les ressources Type1, Type1C et CIDFontType0C brutes d'origine via le chemin d'annotations raw-font d'origine ; les entrées OpenType CFF2 empruntent le backend d'apparences statique d'instance par défaut distinct avec conversion de format explicite, plutôt que d'embarquer CFF2 directement dans un flux de police PDF 1.7

Voir HPDFBuildHeadlessTextAppearance et TryGetCompactFontTable