HPDFBuildHeadlessTextAppearance

function HPDFBuildHeadlessTextAppearance(const Text: UnicodeString;
  const TrueTypeFont: SysUtils.TBytes; FirstObjectNumber: Integer;
  const Options: THPDFHeadlessTextAppearanceOptions): THPDFHeadlessTextAppearance;

Construit un vrai Form XObject Unicode et ses objets de polices en utilisant le parser HotPDF partagé, les classes d'objets, le lecteur cmap, les advances TrueType réels et métadonnées de descripteur, et le shaping HarfBuzz/FriBidi optionnel

Le bundle retourné détient sept objets consécutifs à partir d'un FirstObjectNumber positif ; utilisez la méthode d'apparence du document pour l'enregistrement d'objets, les liens de champs, le chiffrement et la sortie incrémentale bornée

La police exige des contours TrueType glyf/loca nommés, une signature sfnt et un magic head cohérents, des offsets de glyphes ordonnés et bornés, et un cmap Unicode complet valide contenu dans l'étendue de table déclarée

La recherche Unicode ne retombe pas sur des mappages Symbol ou MacRoman ; les glyphes manquants sont rejetés au lieu d'être remplacés par un glyphe visuellement sans rapport

Le texte pris en charge est le latin, grec, cyrillique horizontaux directs, le CJK simple, le Hangul précomposé, des symboles mathématiques sélectionnés et les emoji isolés quand la police fournie contient chaque scalaire

Le layout multiligne CR/LF, le wrapping mesuré, les cellules comb, les rotations d'un quart de tour et les bordures rectangulaires ou circulaires sont contrôlés par le record d'options

Avec ShapeComplexText activé, les scripts complexes, séquences combinantes, bidi et ligatures utilisent le shaping HarfBuzz natif et l'ordonnancement de runs FriBidi ; les surrogates malformés, caractères de contrôle non pris en charge, glyphes manquants, permissions de police invalides et budgets épuisés restent des erreurs

Les glyphes complexes reçoivent un positionnement individuel incluant les offsets de shaping, des mappages ToUnicode conscients des clusters et un ActualText de marked-content conservant la source logique ; les lecteurs peuvent utiliser leur propre ordre d'extraction de texte d'annotations

Linux charge libharfbuzz.so.0 et libfribidi.so.0 ; Windows exige libharfbuzz-0.dll et libfribidi-0.dll d'architecture correspondante, avec des chemins explicites optionnels via HOTPDF_HARFBUZZ_LIBRARY et HOTPDF_FRIBIDI_LIBRARY

Les octets de police d'origine complets sont embarqués avec leur nom PostScript réel, bounds, ascent, descent, angle italique et drapeau fixed-pitch ; la hauteur des capitales utilise OS/2 quand disponible et sinon l'ascender hhea, tandis que StemV utilise une estimation prudente de descripteur fixe

L'embarquement installable ou editable est requis ; le no-subsetting est honoré par l'embarquement complet, et les permissions d'embarquement restricted, preview-and-print, bitmap-only, absentes ou inconnues sont rejetées

Le builder vérifie les octets de police, le nombre de glyphes, les tailles de streams et dictionnaires, la validité scalaire et l'annulation avant de retourner un bundle détenu

Voir THPDFHeadlessTextAppearanceOptions, THPDFHeadlessTextAppearance et SetTextFieldValueWithAppearance

Les polices OpenType CFF 1 sont prises en charge via le backend d'apparences de police compact, avec police complète, mapping CID réel, texte Unicode, widths et politique d'embarquement