Avances des polices standard

Le texte PDF simple chargé sans /Widths utilise les avances horizontales des core-fonts Adobe pour les caractères pris en charge, évitant la dérive cumulative de position quand un substitut installé a des métriques différentes

Contrat pris en charge

Chaque face a 230 entrées Unicode décodées : ASCII imprimable, Latin-1 et caractères Windows-1252 imprimables définis, plus i sans point, Lslash, lslash, caron, breve, dotaccent, ring, ogonek, hungarumlaut, fraction, fi et fl

U+00A0 utilise l'avance de l'espace et U+00AD celle du trait d'union ; U+00B5 est le signe micro Latin-1, tandis que le U+03BC grec est hors du tableau

L'octet 39 brut en StandardEncoding décode en U+2019 quoteright ; l'octet 39 en WinAnsi décode en U+0027 quotesingle, qui a une avance Helvetica différente

Les noms avec préfixes de subset, les alias comme Arial ou Courier New, les casses différentes, Symbol, ZapfDingbats, les caractères de contrôle, les lettres grecques et les autres Unicode non pris en charge conservent le comportement de fallback existant

Les /Widths PDF explicites sont préservés, y compris les avances délibérément personnalisées ; les programmes de polices et les maps d'encodage restent séparés de ces tableaux, et une fixture TrueType embarquée avec des largeurs explicites est couverte par les tests d'acceptation

Ce ne sont que des avances horizontales ; elles ne fournissent pas de contours de glyphes, de bounding boxes, de métriques verticales, de shaping de ligatures ni de kerning, et un renderer peut toujours peindre avec un substitut installé tout en positionnant le texte à partir des avances standard

Mesure et état de texte

HPDFGetStandardFontWidth effectue une consultation immuable de tableau ; HPDFMeasureBaseFontWidths combine ces résultats avec le backend de plateforme existant quand un lot contient des caractères de fallback

L'interpréteur de contenu continue d'appliquer la taille de police, Tc, Tw, Tz, les ajustements TJ, les matrices de texte et la transformation graphique après la résolution de l'avance ; les tableaux n'ajoutent pas de kerning automatique au texte PDF

Validation et frontières de lecteurs indépendants

L'acceptation ciblée construit 15 véritables pages PDF couvrant les 12 faces, les quotes et ligatures StandardEncoding, la ponctuation et le texte accentué WinAnsi, les largeurs explicites, un programme TrueType embarqué et du texte TJ transformé ; les origines natives des glyphes sont comparées avec un lecteur MuPDF indépendant

La sonde d'avances Unicode vérifie les 2 760 entrées du tableau ; 2 756 concordent avec MuPDF, tandis que les quatre entrées fraction U+2044 de la famille Helvetica conservent le WX 167 de l'AFM Adobe et sont rapportées explicitement parce que MuPDF retourne l'avance 278 de type slash pour ce caractère

La comparaison de géométrie PDF partagée utilise les caractères sur lesquels le lecteur indépendant concorde ; la différence de fraction n'est pas rapportée comme une équivalence inter-lecteurs réussie

L'acceptation Windows utilise Tests/Delphi/Run-StandardFontMetricsAcceptance.ps1 et rejoue aussi les suites existantes d'extraction de texte et de largeurs ; l'acceptation Linux native utilise Tests/Linux/Run-StandardFontMetricsAcceptance.sh avec les overrides FPC_EXE, PYTHON_EXE et HPDF_LINUX_OUTPUT

Toutes les exécutions suppriment le lancement de lecteurs externes et émettent des logs natifs, des tableaux d'avances, des coordonnées de glyphes, un aperçu rendu et un rapport independent-proof.json

Base métrique

Les avances sont les faits WX AFM des core-fonts Adobe en 1/1000 em ; la convention de coordonnées et de métriques est documentée dans la spécification Adobe Font Metrics