Arabic / Persian / Urdu Shaping Support

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

OpenType GSUB Engine CFF / OpenType Subsetting

HotPDF vykdo formavimo vamzdį kūrėjo pusėje, kuris Unicode įvesties arabų, persų ir urdų fragmentus suspaudžia į atitinkamas Arabic Presentation Forms formos metu PDF teksto generavimo metu, todėl vartotojo skaityklos gauna iš karto pateikiamus pozicinius / ligatūrinius glifus nereikalaudamos savarankiško Harfbuzz tipo formavimo modulio

What the pipeline does

Pozicinis formavimas (v2.85.0): kiekviena arabų bazinė raidė turi iki keturių pozicinių formų - isolated (isol), initial (init), medial (medi), final (fina). HotPDF tikrina kiekvieno arabiško simbolio jungimo klasę ir jo kaimynų jungimo klases, o tada prieš išvedimą susieja įvesties kodo tašką su atitinkamu Arabic Presentation Forms-B (U+FE70 - U+FEFC) glifu. Nejungiantys simboliai, jungikliai, permatomi simboliai (kombinuojantys ženklai) ir Tatweel kashida apdorojami pagal Unicode Arabic Shaping algoritmą

Privalomas LAM-ALEF junginys (v2.119.32): Arabic Unicode Shaping specifikacija numato, kad bet kuris LAM (U+0644), iškart po kurio eina ALEF (U+0627 paprastas, U+0622 su madda viršuje, U+0623 su hamza viršuje, U+0625 su hamza apačioje), susilanksto į vieną junginio glifą (U+FEFB - U+FEFC isolated / final formos su atitinkamais hamza / madda variantais). Tai vienas iš labai nedaugelio nepasirenkamų junginių arabų tipografijoje ir yra būtinas teisingumui; atvaizdavus juos kaip atskirus glifus, tekstas vietiniams skaitytojams iškart atrodo netaisyklingas. HotPDF šį susilankstymą atlieka išvedimo metu, todėl kviestinėms pusėms savo kode nereikia Harfbuzz klasės formuotojo

Persų / Urdu pagrindinės 9 raidės (v2.119.35): persų ir urdu kalbos papildo arabų raštą raidėmis, kurių nėra Arabic Presentation Forms-B bloke (U+FE70 - U+FEFC). 9 dažniausiai naudojamos tokios raidės - įskaitant 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) ir HEH GOAL (U+06C1) - turi presentation formas Arabic Presentation Forms-A (U+FB50 - U+FDFF). HotPDF dabar, formuodamas pozicijas, šias raides susieja su tinkamais Forms-A glifais, todėl persų ir urdu tekstas bet kuriame skaitytuve rodomas su teisingomis init / medi / fina / isol formomis

Arabic Extended-A + Supplement (v2.119.52, v2.119.56): jungimo klasių lentelė dabar apima likusius Arabic Extended-A simbolius (ALEF WASLA / NOON GHUNNA / HEH variantus), Arabic Supplement U+0750-U+077F ir aukštesnį Arabic Extended-A U+08A0-U+08FF diapazoną. Simboliai su statiniu Presentation Forms-A kodavimu yra susiejami per esamą 4 padėčių šaperį; simboliai be jo (dauguma Extended-A) gauna tik jungimo klasės klasifikaciją, kad kaimynai būtų teisingai suformuoti net tada, kai pats simbolis perduodamas nepakeistas. v2.119.56 ištaisė du neteisingus Forms-A susiejimus, įvestus v2.119.52 (U+06C2 / U+06C3)

Persian / Urdu Form-B pilna aprėptis (v2.119.57): jungimo klasių lentelė buvo išplėsta, kad apimtų visą U+0672-U+06D5 diapazoną (apie 80 simbolių, apimančių REH / DAL / SEEN / SAD / TAH / AIN / FEH / QAF / KAF / GAF / LAM / NOON / HEH / WAW / YEH variantus), ir pridėta 26 naujų Presentation Forms-A susiejimų (15 D klasės 4 formų + 11 R klasės 2 formų). Ypač urdų standartinis 'h' HEH DOACHASHMEE (U+06BE → FBAA-FBAD) ir urdų žodžio gale esantis yeh YEH BARREE (U+06D2 → FBAE-FBAF) dabar teisingai susiejami su Forms-A vietomis, kurias v2.119.52 ALEF WASLA / NOON GHUNNA laikinas pataisymas naudojo neteisingai. Statinė Forms-A aprėptis dabar apima 40+ šaltinio simbolių

YEH-HAMZA + balsių junginio post-pasas (v2.119.58): po pozicinio formavimo į _ApplyArabicShaping pridėtas post-pasas apima 8 junginių poras Forms-A bloke U+FBEA-U+FBFB - YEH-HAMZA + ALEF / AE / WAW / U / OE / YU / E / ALEF MAKSURA. Kiekviena pora išveda isolated formą (FBEA / FBEC / FBEE / FBF0 / FBF2 / FBF4 / FBF6 / FBF9) ir bazinę+1 final formą. Pradžios / vidurio formų vietos FBF8 / FBFB paliekamos GSUB varikliui per sfArabicGSUB pasirinktinį įjungimą. Sukurta ant tos pačios struktūros kaip v2.119.32 LAM-ALEF

Allah junginys (v2.119.60): keturių simbolių seka ALEF + LAM + LAM + HEH susilanksto į U+FDF2 ARABIC LIGATURE ALLAH ISOLATED FORM. Įgyvendinta kaip statinis post-pasas kodo taško lygiu po v2.119.32 LAM-ALEF ir v2.119.58 YEH-HAMZA _ApplyArabicShaping grandinėje

Bismillah frazės junginys (v2.119.62): standartinė 22 kodo taškų Bismillah frazė "بسم الله الرحمن الرحيم" susilanksto į vieną glifą U+FDFD ARABIC LIGATURE BISMILLAH AR-RAHMAN AR-RAHEEM. Veikia kaip pats pirmas pre-pasas _ApplyArabicShaping grandinėje (prieš LAM-ALEF), todėl sulankstytas Bismillah glifas visą likusią grandinę pasiekia kaip vienas kodo taškas ir nebėra keičiamas vėlesnių pakeitimų

Public Query Helpers

GetArabicJoiningClass grąžina Unicode jungimo klasę, kurią naudoja statinis arabų formuotuvas. GetArabicPosition priskiria vienam simboliui sekoje isolated, initial, medial arba final padėtį, kad kviestinės pusės galėtų prieš išvesdamos tekstą patikrinti arba atkartoti tuos pačius formavimo sprendimus

How callers invoke it

Teksto formavimo grandinė veikia automatiškai Unicode teksto išvedimo metoduose - atskiro „shape this“ kvietimo nereikia. Perduokite Unicode įvesties Arabic / Persian / Urdu eilutes į THPDFPage.UnicodeTextOut arba THPDFPage.RtLTextOut, ir HotPDF prieš rašydamas PDF teksto rodymo operatorių kiekvieną įvesties kodinį tašką paverčia į jo prezentacinę formą. Originalūs Unicode baitai taip pat įrašomi į FUnicodeUsedCps ToUnicode CMap generavimui, todėl skaitytuvo kopijavimas / įklijavimas ir ekrano skaitytuvai vis dar mato originalų Unicode turinį

Font requirements

Per RegisterUnicodeTTF registruojamas šriftas turi turėti glifus tiek Arabic Presentation Forms-B bloke (U+FE70 - U+FEFC), tiek (Persian / Urdu atveju) atitinkamame Arabic Presentation Forms-A intervale (U+FB50 - U+FDFF). Rekomenduojami šriftai, kuriuose yra visas rinkinys:

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).

Kai registruotame šrifte trūksta išvestinės prezentacinės formos glifo, HotPDF grįžta prie bazinio Unicode kodinio taško ir išveda jį nepakeistą; vartotojo skaitytuvai gali bandyti savo formavimą (Acrobat, Foxit) arba rodyti .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 pristatė pasirenkamus ShapingFeatures: THPDFShapingFeatures property ir THPDFShapingFeature enum, kurie formavimo grandinę pakelia už statinio post-paso sulankstymo į automatinį GSUB pagrįstą šriftui būdingą pakeitimą. Nustatykite PDF.ShapingFeatures := [sfArabicGSUB], kad būtų taikomi registruoto šrifto vietiniai arabų init, medi, fina, isol, rlig, calt ir rclt lookup'ai ir išvedami atitinkami kontekstiniai glifų ID; pridėkite sfCursiveAttachment, kad tam suformuotam tekstui būtų taikomi GPOS kursyviniai įėjimo ir išėjimo inkarai; pridėkite sfStandardLigatures Latin Standard Ligatures (FB00-FB06 ff / fi / fl / ffi / ffl / ſt / st per v2.119.65 ApplyLatinLigatureRefinement); pridėkite sfIndicShaping, kad būtų įjungtas Devanagari pre-paso pertvarkymas (v2.119.67). Numatytoji [] išlaiko baitas į baitą identišką išvestį kviestinėms pusėms, kurios priklauso nuo statinio vamzdyno

Kai nustatytas sfArabicGSUB, statinis Unicode Presentation Forms formuotuvas apeinamas ir naudojamos paties šrifto GSUB taisyklės. HotPDF išveda vietinius kontekstinius glifų ID per sintetinius kodinius taškus, kai tų glifų negalima pasiekti iš šrifto cmap, išlaiko uždarą įdėtą pogrupį ir rašo ToUnicode atvirkštinius susiejimus kopijavimui ir įklijavimui. Kūrėjai, norintys, kad statinis formuotuvas toliau veiktų kodinių taškų aprėpčiai už to, ką deklaruoja šrifto GSUB, turėtų palikti sfArabicGSUB išjungtą ir remtis statine post-pass grandine

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

RegisterUnicodeTTF išleidžiamas Adobe-Identity-UCS ToUnicode CMap prideda bfchar atvirkštinio susiejimo įrašus kiekvienam junginio kodo taškui, kurį gali sukurti post-pasų grandinė. v2.119.61 pridėjo 27 įrašus (8 LAM-ALEF + 18 YEH-HAMZA šeimos + 1 Allah); v2.119.62 pridėjo Bismillah (U+FDFD); v2.119.65 pridėjo 7 Latin Standard Ligature įrašus (FB00-FB06). Vartotojo skaitytuvo copy / paste bet kurį junginio glifą susieja atgal su šaltinio kodo taškų seka, todėl atvaizduotas PDF išlieka prieinamas

PUA synthetic codepoint emit (v2.119.68)

AssignSyntheticCodepointForGID(GID; out CP): Boolean + GetSyntheticCodepointForGID(GID): Word leidžia gamintojo pusės kodui išvesti GSUB pakaitinius GID, kurie neturi natūralaus Unicode kodo taško, pasiekiamo per šrifto cmap. Skirstytuvas išduoda kodo taškus Private Use Area (U+E000 - U+F8FF, 6400 vietų) ir atspindi priskyrimą į FUnicodeCpToGid (kad /CIDToGIDMap vartotojo skaitytuve susietų sintetinį CP atgal su tiksliniu GID), FAcroFormUnicodeAdvances (kad v2.65 žodžių laužymas rastų teisingą em dalį) ir į per GID atvirkštinės paieškos lentelę (kad kartotiniai priskyrimai būtų idempotentiniai). Naudokite tai Devanagari klasterių formoms, stilistinėms alternatyvoms ir CJK ideografinėms variacijų sekoms, kurias sukuria GSUB, bet nepasiekia cmap

Relationship to the OpenType GSUB engine

Aukščiau aprašytas statinis post-pass formuotuvas (v2.85.0 + v2.119.32 / 58 / 60 / 62) pagal numatymą nepriklauso nuo OpenType GSUB variklio. Kai per ShapingFeatures įjungiamas sfArabicGSUB, GSUB variklis tampa išvesties pusės generavimo kelio dalimi: HotPDF peržiūri cmap, kad sudarytų bazinį GID masyvą, taiko vietines Arabic pozicines ir kontekstines GSUB paieškas tam glifų srautui, priskiria sintetinius kodinius taškus pakaitinių glifų ID, kurie neturi Unicode Presentation Formos, ir kviečia MarkUnicodeGlyphUsed, kad pakaitiniai glifai liktų įdėtame šrifto pogrupyje

Pakaitiniams glifams be Unicode kodinio taško kūrėjai sujungia ShapingFeatures su v2.119.68 PUA sintetinių kodinių taškų skirstytuvu, kad pakaitinis GID vis dar būtų pasiekiamas per standartinį hex srautą. Statinė post-pass grandinė išlieka numatytasis rezervinis kelias tiems kodiniams taškams, kurių šrifto GSUB deklaracijos neapima

Scope and limitations

BiDi algoritmas šiame puslapyje neaptariamas: kūrėjai vis dar turi patys sutvarkyti mišrias LTR ir RTL atkarpas arba naudoti atskirą BiDi biblioteką. GPOS, Indic/Tibetan/Mongolian, Hebrew, N'Ko, Adlam, Thai/Lao ir Javanese palaikymas dabar gyvena atskiruose pasirenkamuose formavimo vėliavų ir API puslapiuose, todėl šiame puslapyje dėmesys skiriamas tik statiniam ir GSUB pagrįstam Arabic formavimui