Prise en charge du façonnage syriaque / mongol / devanagari

Surfaces de capacités multigraphies (v2.119.53 - v2.119.55)

HotPDF expose des surfaces de capacité pour les classes de jonction, l’analyse positionnelle et les catégories syllabiques Indic pour trois écritures complexes en plus de l’arabe : le syriaque (U+0700-U+074F), le mongol (U+1800-U+18AF) et le devanagari (U+0900-U+097F) Chaque capacité permet aux appelants de piloter l’écriture via le moteur OpenType GSUB existant pour un façonnage correct, tout en laissant le gros du travail (détection des limites de cluster, résolution BiDi, positionnement GPOS) hors du périmètre de HotPDF

Capacité de façonnage Syriac (v2.119.53)

Deux nouvelles méthodes exposent le comportement de jonction Syriac :

function GetSyriacJoiningClass(CP: Cardinal): TJoiningClass;

function GetSyriacPosition(const Run: array of Cardinal; Index: Integer): TPosition;

Le syriaque suit le même cadre à quatre classes Right-Joining / Dual-Joining / Transparent / Non-Joining que l’arabe ; GetSyriacJoiningClass classe chaque point de code du bloc U+0700-U+074F selon la propriété Unicode de jonction GetSyriacPosition parcourt une séquence syriaque et résout chaque caractère vers sa position isolée / initiale / médiane / finale en fonction des classes de jonction de ses voisins immédiats

Contrairement à l’arabe, le bloc syriaque n’a aucune forme de présentation préencodée dans Unicode - il n’existe pas d’équivalent syriaque aux blocs Arabic Presentation Forms U+FB50-FDFF / U+FE70-FEFC Les consommateurs doivent donc piloter le façonnage syriaque par des recherches GSUB définies par la police (généralement init / medi / fina / isol + rlig) plutôt que par réécriture de points de code La couche de capacité ci-dessus fournit aux appelants les étiquettes de position nécessaires pour interroger la bonne fonctionnalité GSUB pour chaque glyphe

Capacité de façonnage mongol (v2.119.54)

Deux méthodes parallèles pour Mongolian :

function GetMongolianJoiningClass(CP: Cardinal): TJoiningClass;

function GetMongolianPosition(const Run: array of Cardinal; Index: Integer): TPosition;

La couverture inclut le mongol de base (U+1820-U+1842), Todo (U+1843-U+1877), Sibe (U+1880-U+18A8), Manchu et les extensions Ali Gali Les sélecteurs de variation FVS1 / FVS2 / FVS3 (U+180B-U+180D), le trait d’union souple NIRUGU (U+180A) et les marques vocaliques Ali Gali sont tous classés comme Transparent (classe T) afin de participer à la jonction sans casser le parcours

Comme le syriaque, le mongol n’a pas de formes de présentation préencodées dans Unicode La mise en page verticale traditionnelle du mongol, ses règles complexes de variation de forme de lettre et la sélection de forme pilotée par FVS sont toutes censées être gérées par des recherches GSUB définies par la police (généralement init / medi / fina / isol + ccmp / rlig / locl) ; la couche de capacité fournit aux appelants les étiquettes de position nécessaires pour interroger ces fonctionnalités

Capacité de façonnage Indic Devanagari (v2.119.55)

Le devanagari est fondamentalement différent de l’arabe / syriaque / mongol - c’est une écriture abugida Indic où l’unité porteuse de sens est un groupe syllabique (akshara), pas une lettre unique, et l’ordre rendu des glyphes à l’intérieur d’un cluster diffère souvent de l’ordre logique Unicode Deux méthodes exposent la couche de capacité Indic du devanagari :

function GetDevanagariCategory(CP: Cardinal): TIndicCategory;

procedure ApplyDevanagariReorder(var Run: array of Cardinal);

GetDevanagariCategory classe chaque point de code de U+0900-U+097F dans l’une des 13 catégories syllabiques Indic (Base / Consonant / Vowel / Independent Vowel / Vowel Mark / Pre-base Matra / Above-base Matra / Below-base Matra / Halant Virama / Repha / Anusvara / Visarga / Other) afin que les appelants puissent détecter les limites de syllabe et identifier quelles positions à l’intérieur de chaque cluster nécessitent un réordonnancement

ApplyDevanagariReorder est un pré-pass qui parcourt la séquence d’entrée et applique les deux principales règles de réordonnancement du devanagari : (1) Repha (Ra + Halant au début d’un cluster syllabique) est déplacé après la consonne de base du cluster afin d’être rendu comme un crochet en exposant ; (2) la matra I pré-base (U+093F DEVANAGARI VOWEL SIGN I) est déplacée avant la consonne de base du cluster afin d’être rendue comme un crochet à gauche Les autres réordonnancements Indic (matra au-dessus de la base, matra au-dessous de la base, formation de conjonctions) sont laissés au moteur GSUB de la police car ils nécessitent des tables de recherche propres à la police

Intégration automatique (v2.119.67) : lorsque sfIndicShaping in PDF.ShapingFeatures est défini, ApplyDevanagariReorder est appliqué automatiquement comme pré-pass à l’intérieur des trois aides BuildUnicode*FieldContent Le moteur GSUB du lecteur consommateur récupère alors la syllabe dans le bon ordre et applique ses propres règles de façonnage contextuel Voir Automatic Shaping Pipeline

Type de flux (Syriac)

PDF.RegisterUnicodeTTF('Estrangelo', 'SyrCOMEdessa.otf');

PDF.SetGSUBScript('syrc');  // see GSUB engine doc

for i := 0 to Length(Run) - 1 do

begin

  Pos := PDF.GetSyriacPosition(Run, i);  // init / medi / fina / isol

  // query GSUB for the position-appropriate substitute glyph

  // emit + MarkUnicodeGlyphUsed

end;

Type de flux (Devanagari avec réordonnancement automatique)

PDF.RegisterUnicodeTTF('NotoDeva', 'NotoSansDevanagari-Regular.ttf');

PDF.ShapingFeatures := [sfIndicShaping];  // auto Repha + I-matra reorder

PDF.CurrentPage.SetFont('NotoDeva', [], 14);

PDF.CurrentPage.UnicodeTextOut(50, 700, 0,

  UnicodeString(#$0939#$093F#$0928#$094D#$0926#$0940)); // "Hindi"

Helpers Unicode de sous-ensemble et d’extraction

RegisterToUnicodeReverseMapping enregistre les points de code source pour la sortie de glyphes façonnés ou synthétiques ClearToUnicodeReverseMappings réinitialise la table, ToUnicodeReverseMappingCount en indique la taille, GetUnicodeGlyphForCodepoint renvoie l’ID de glyphe de la police enregistrée pour un point de code Unicode, et EnableShapingFeatureForSubset marque les glyphes substituts d’une fonctionnalité GSUB pour inclusion dans le sous-ensemble embarqué

Portée et limites

Intégration producteur actuelle

Les façonnages Syriac, Mongolian, Tibetan et Indic disposent maintenant de pages de référence API explicites Syriac peut être activé par AutoShapeSyriac, Mongolian par sfMongolianShaping, Tibetan par sfTibetanShaping, le réordonnancement Indic par sfIndicShaping et le façonnage Indic GSUB complet par sfIndicGSUB Les points d’entrée détaillés sont documentés dans Tibetan/Mongolian/Syriac shaping methods et Indic shaping methods

La portée actuelle couvre aussi N'Ko et Adlam comme écritures cursives RTL, Thai/Lao pour SARA AM et les tons, Hebrew pour l’ordre des niqqud et Javanese pour les signes pré-base Ces chemins sont documentés dans script shaping preprocess methods

Voir aussi: Prise en charge du façonnage arabe / persan / ourdou, Automatic Shaping Pipeline (Phase 8), OpenType GSUB Substitution Engine, THotPDF.AssignSyntheticCodepointForGID