Arabic / Persian / Urdu Shaping Support

Producer-side shaping pipeline (v2.85.0 - v2.119.68)

OpenType GSUB Engine CFF / OpenType Subsetting

HotPDF spúšťa tvarovaciu pipeline na strane producenta, ktorá pri emitovaní PDF textu skladá arabské, perzské a urdské behy z Unicode vstupu do ich Arabic Presentation Forms, takže čítačky na strane konzumenta dostanú už pripravené pozičné / ligatúrne glyfy bez potreby vlastného tvarovača triedy Harfbuzz

What the pipeline does

Polohové tvarovanie (v2.85.0): každé základné arabské písmeno má až štyri polohové formy - isolated (isol), initial (init), medial (medi), final (fina). HotPDF skúma triedu spájania každého arabského znaku a triedy spájania jeho bezprostredných susedov a potom pred odoslaním mapuje vstupný codepoint na príslušný glyf z Arabic Presentation Forms-B (U+FE70 - U+FEFC). Nespojovacie písmená, spojky, transparentné znaky (kombinačné značky) a Tatweel kashida sa spracúvajú podľa algoritmu Unicode Arabic Shaping

Povinná ligatúra LAM-ALEF (v2.119.32): špecifikácia Arabic Unicode Shaping vyžaduje, aby sa každé LAM (U+0644) bezprostredne nasledované ALEF (U+0627 základné, U+0622 s madda hore, U+0623 s hamza hore, U+0625 s hamza dole) zlúčilo do jedného ligatúrneho glyfu (U+FEFB - U+FEFC v izolovanej / záverečnej forme s príslušnými variantmi hamza / madda). Ide o jednu z veľmi mála nepovinných ligatúr v arabskom písme a je nutná pre správnosť; vykreslenie ako samostatných glyfov vytvorí text, ktorý rodní čitatelia okamžite rozpoznajú ako chybný. HotPDF zlúčenie vykoná pri emitovaní, takže volajúci nepotrebujú vo vlastnej ceste tvarovač triedy Harfbuzz

Základných 9 perzských a urdských písmen (v2.119.35): perzština a urdčina rozširujú arabské písmo o písmená, ktoré nie sú v bloku Arabic Presentation Forms-B (U+FE70 - U+FEFC). Deväť najpoužívanejších takýchto písmen - vrátane PEH (U+067E), TCHEH (U+0686), JEH (U+0698), KEH (U+06A9 / U+06AF), GAF (U+06AF), NOON GHUNNA (U+06BA), HEH DOACHASHMEE (U+06BE), YEH BARREE (U+06D2) a HEH GOAL (U+06C1) - má prezentačné formy v Arabic Presentation Forms-A (U+FB50 - U+FDFF). HotPDF teraz počas polohového tvarovania mapuje tieto písmená na príslušné glyfy Forms-A, takže perzský a urdský text sa v ľubovoľnom čítači vykreslí so správnymi formami init / medi / fina / isol

Arabic Extended-A + Supplement (v2.119.52, v2.119.56): tabuľka tried spájania teraz pokrýva zostávajúce znaky Arabic Extended-A (ALEF WASLA / NOON GHUNNA / varianty HEH), Arabic Supplement U+0750-U+077F a vyšší rozsah Arabic Extended-A U+08A0-U+08FF. Znaky so statickým kódovaním Presentation Forms-A sa mapujú cez existujúci 4-polohový tvarovač; znaky bez neho (väčšina Extended-A) dostanú iba klasifikáciu triedy spájania, takže susedia sa tvarujú správne aj vtedy, keď samotný znak prejde bez zmeny. v2.119.56 opravila dve nesprávne mapovania Forms-A zavedené vo v2.119.52 (U+06C2 / U+06C3)

Úplné pokrytie Persian / Urdu Form-B (v2.119.57): tabuľka tried spájania bola rozšírená na celý rozsah U+0672-U+06D5 (asi 80 znakov pokrývajúcich varianty REH / DAL / SEEN / SAD / TAH / AIN / FEH / QAF / KAF / GAF / LAM / NOON / HEH / WAW / YEH) a bolo pridaných 26 nových mapovaní Presentation Forms-A (15 D-triednych 4-foriem + 11 R-triednych 2-foriem). Najmä štandardné urdské 'h' HEH DOACHASHMEE (U+06BE → FBAA-FBAD) a koncové urdské yeh YEH BARREE (U+06D2 → FBAE-FBAF) sú teraz správne mapované na sloty Forms-A, ktoré sa vo v2.119.52 dočasne zneužili pre ALEF WASLA / NOON GHUNNA. Statické pokrytie Forms-A teraz zahŕňa viac ako 40 zdrojových znakov

Dodatočný post-pass YEH-HAMZA + samohlásková ligatúra (v2.119.58): post-pass pridaný do _ApplyArabicShaping po polohovom tvarovaní pokrýva 8 párov ligatúr v bloku Forms-A U+FBEA-U+FBFB - YEH-HAMZA + ALEF / AE / WAW / U / OE / YU / E / ALEF MAKSURA. Každý pár emitujte v izolovanej forme (FBEA / FBEC / FBEE / FBF0 / FBF2 / FBF4 / FBF6 / FBF9) plus finálnu formu base+1. Počiatočné / stredné sloty foriem FBF8 / FBFB zostávajú na engine GSUB cez zapnutie sfArabicGSUB. Postavené na rovnakej kostre ako v2.119.32 LAM-ALEF

Ligatúra Allah (v2.119.60): štvorznaková sekvencia ALEF + LAM + LAM + HEH sa skladá do U+FDF2 ARABIC LIGATURE ALLAH ISOLATED FORM. Je implementovaná ako statický post-pass na úrovni codepointov po v2.119.32 LAM-ALEF a v2.119.58 YEH-HAMZA v reťazci _ApplyArabicShaping

Ligatúra frázy Bismillah (v2.119.62): štandardná 22-codepointová fráza Bismillah "بسم الله الرحمن الرحيم" sa skladá do jediného glyfu U+FDFD ARABIC LIGATURE BISMILLAH AR-RAHMAN AR-RAHEEM. Spúšťa sa ako úplne prvý pre-pass v _ApplyArabicShaping (pred LAM-ALEF), takže zložený glyf Bismillah vstúpi do zvyšku pipeline ako jeden codepoint a následné substitúcie ho už neupravujú

Public Query Helpers

GetArabicJoiningClass vracia triedu spájania Unicode používanú statickým arabským tvarovačom. GetArabicPosition rozlíši jeden znak v behu na izolovanú, počiatočnú, strednú alebo záverečnú pozíciu, aby volajúci mohli pred emitovaním textu skontrolovať alebo napodobniť rovnaké rozhodnutia o tvarovaní

How callers invoke it

Tvarovacia pipeline beží automaticky v metódach výstupu Unicode textu - nie je potrebné žiadne explicitné volanie typu "shape this". Odovzdajte arabské / perzské / urdské reťazce v Unicode do THPDFPage.UnicodeTextOut alebo THPDFPage.RtLTextOut a HotPDF pred zápisom PDF text-showing operátora mapuje každý vstupný codepoint na jeho prezentačný tvar. Pôvodné bajty Unicode sa zároveň zachytávajú do FUnicodeUsedCps na generovanie ToUnicode CMap, takže kopírovanie / vkladanie na strane čítačky a čítačky obrazovky stále vidia pôvodný Unicode payload

Font requirements

Font registrovaný cez RegisterUnicodeTTF musí obsahovať glyfy pre blok Arabic Presentation Forms-B (U+FE70 - U+FEFC) a (pre perzštinu / urdčinu) aj pre príslušný rozsah Arabic Presentation Forms-A (U+FB50 - U+FDFF). Odporúčané fonty, ktoré dodávajú celú sadu:

Noto Sans Arabic (Latin + Arabic; Forms-A + Forms-B + Arabic Extended-A).

Noto Naskh Arabic, Noto Naskh Arabic UI.

Amiri (traditional Naskh, full Forms-A + Forms-B coverage).

Scheherazade New (SIL, designed for languages of the Muslim world).

Microsoft Arabic Typesetting / Tahoma / Times New Roman (Windows-bundled, full Forms-B; some have Forms-A coverage).

Ak registrovanému fontu chýba glyf pre odvodený prezentačný tvar, HotPDF sa vráti k základnému Unicode codepointu a odošle ho nezmenený; spotrebiteľské čítačky potom môžu skúsiť vlastné tvarovanie (Acrobat, Foxit) alebo vykresliť .notdef

Typical workflow

PDF.RegisterUnicodeTTF('NotoArab', 'NotoSansArabic-Regular.ttf');

PDF.BeginDoc;

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

PDF.CurrentPage.RtLTextOut(100, 700, 0,

UnicodeString(#$0645#$0631#$062D#$0628#$0627)); // "marhaba" (hello)

PDF.EndDoc;

Automatic Phase 8 pipeline integration (v2.119.59 - v2.119.68)

v2.119.59 introduced the opt-in ShapingFeatures: THPDFShapingFeatures property and the THPDFShapingFeature enum, which elevates the shaping pipeline beyond static post-pass folding into automatic GSUB-driven font-specific substitution. Set PDF.ShapingFeatures := [sfArabicGSUB] to apply the registered font's native Arabic init, medi, fina, isol, rlig, calt, and rclt lookups and emit the resulting contextual glyph IDs; add sfCursiveAttachment to apply GPOS cursive entry/exit anchors to that shaped run; add sfStandardLigatures for Latin Standard Ligatures (FB00-FB06 ff / fi / fl / ffi / ffl / ſt / st via v2.119.65 ApplyLatinLigatureRefinement); add sfIndicShaping to enable the Devanagari pre-pass reorder (v2.119.67). Default [] preserves byte-identical output for callers who depend on the static pipeline.

Keď je nastavené sfArabicGSUB, statický tvarovač Unicode Presentation Forms sa obíde v prospech vlastných GSUB pravidiel fontu. HotPDF emituje natívne kontextové GID glyfy cez syntetické codepointy, keď tieto glyfy nie sú dosiahnuteľné z cmap fontu, ponecháva vložený subset uzavretý a zapisuje spätné mapovania ToUnicode pre kopírovanie a vkladanie. Volajúci, ktorí chcú, aby statický tvarovač naďalej bežal pre pokrytie codepointov mimo toho, čo deklaruje GSUB fontu, by mali nechať sfArabicGSUB vypnuté a spoliehať sa na statický post-pass reťaz

ToUnicode CMap ligature reverse mapping (v2.119.61, v2.119.62, v2.119.65)

Adobe-Identity-UCS ToUnicode CMap emitovaný cez RegisterUnicodeTTF dodáva bfchar položky spätného mapovania pre každý codepoint ligatúry, ktorý môže reťazec po spracovaní vytvoriť. v2.119.61 pridala 27 položiek (8 LAM-ALEF + 18 rodiny YEH-HAMZA + 1 Allah); v2.119.62 pridala Bismillah (U+FDFD); v2.119.65 pridala 7 položiek Latin Standard Ligature (FB00-FB06). Kopírovanie / vkladanie na strane spotrebiteľskej čítačky mapuje ľubovoľný glyf ligatúry späť na zdrojovú postupnosť codepointov, takže vykreslené PDF zostáva prístupné

PUA synthetic codepoint emit (v2.119.68)

AssignSyntheticCodepointForGID(GID; out CP): Boolean + GetSyntheticCodepointForGID(GID): Word umožňujú producentovi emitovať náhradné GID z GSUB, ku ktorým nevedie žiadny prirodzený Unicode codepoint cez cmap písma. Alokátor prideľuje codepointy v oblasti Private Use Area (U+E000 - U+F8FF, 6400 miest) a zrkadlí priradenie do FUnicodeCpToGid (aby /CIDToGIDMap mapoval syntetický CP späť na cieľové GID na strane čítača), FAcroFormUnicodeAdvances (aby v2.65 zalamovanie slov našlo správny zlomok em) a do reverznej tabuľky pre každé GID (aby opakované požiadavky na priradenie boli idempotentné). Použite to pre tvary devanagárskych klastrov, štýlové alternatívy a sekvencie ideografických variácií CJK, ktoré GSUB zavádza, ale cmap nedosahuje

Relationship to the OpenType GSUB engine

Statický post-pass tvarovač opísaný vyššie (v2.85.0 + v2.119.32 / 58 / 60 / 62) je predvolene nezávislý od OpenType GSUB engine. Keď je cez ShapingFeatures zapnuté sfArabicGSUB, GSUB engine sa stáva súčasťou cesty výstupu na strane producenta: HotPDF konzultuje cmap na zostavenie poľa základných GID, aplikuje natívne arabské pozičné a kontextové GSUB lookupy na tento sled glyfov, priraďuje syntetické codepointy substitučným ID glyfov, ktoré nemajú Unicode Presentation Form, a volá MarkUnicodeGlyphUsed na udržanie substitučných glyfov vo vloženom fontovom subsete

Pre substitučné glyfy bez Unicode codepointu spájajú volajúci ShapingFeatures s PUA syntetickým codepoint allocatorom z v2.119.68, aby bol substitučný GID stále dosiahnuteľný cez štandardný hex pipeline. Statický post-pass reťaz zostáva predvolenou záložnou voľbou pre codepointy, ktoré GSUB deklarácie fontu nepokrývajú

Scope and limitations

Algoritmus BiDi zostáva mimo tejto stránky: volajúci musia zmiešané LTR a RTL behy stále zoradiť sami alebo použiť samostatnú BiDi knižnicu. Podpora GPOS, Indic/Tibetan/Mongolian, Hebrew, N'Ko, Adlam, Thai/Lao a Javanese teraz žije na samostatných opt-in shaping flag a API stránkach, takže táto stránka sa sústreďuje len na statické arabské tvarovanie a tvarovanie založené na GSUB