Støtte for arabisk / persisk / urdu-forming

Produsentside shaping-pipeline (v2.85.0 - v2.119.68)

HotPDF kjører en produsentside formingspipeline som folder Unicode-inndata for arabisk, persisk og urdu inn i arabiske presentasjonsformer under PDF-tekstutslipp, slik at forbrukerlesere mottar posisjons- og ligaturglyfer klare for gjengivelse uten å trenge en egen formingmotor i Harfbuzz-klassen

Hva pipelinen gjør

Posisjonell forming (v2.85.0): hver arabisk grunnbokstav har opptil fire posisjonsformer - isolert (isol), innledende (init), medial (medi) og final (fina). HotPDF undersøker join-klassen for hvert arabiske tegn og join-klassene til de nærmeste naboene, og mapper deretter inndatakodepunktet til riktig glyf i arabiske presentasjonsformer-B (U+FE70 - U+FEFC) før utskrift. Ikke-tilknyttende bokstaver, koblere, transparente tegn (kombinerende merker) og Tatweel-kashidaen håndteres alle etter Unicode-algoritmen for arabisk forming

Obligatorisk LAM-ALEF-ligatur (v2.119.32): spesifikasjonen for arabisk Unicode-forming krever at enhver LAM (U+0644) som umiddelbart følges av en ALEF (U+0627 ren, U+0622 med madda over, U+0623 med hamza over, U+0625 med hamza under) foldes til én ligaturglyf (U+FEFB - U+FEFC isolerte / finale former med passende hamza / madda-varianter). Dette er en av de svært få ikke-valgfrie ligaturene i arabisk typografi og er nødvendig for korrekthet; å rendere dem som separate glyfer gir tekst som morsmålslesere umiddelbart oppfatter som feil. HotPDF utfører foldingen under utsending, slik at kallere ikke trenger en formingmotor i Harfbuzz-klassen i sin egen kodebane

Kjerne med 9 persiske / urdu-bokstaver (v2.119.35): persisk og urdu utvider arabisk med bokstaver som ikke finnes i arabiske presentasjonsformer-B-blokken (U+FE70 - U+FEFC). De 9 mest brukte slike bokstavene - inkludert 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) og HEH GOAL (U+06C1) - har presentasjonsformer i arabiske presentasjonsformer-A (U+FB50 - U+FDFF). HotPDF mapper nå disse bokstavene til riktig presentasjonsformer-A-glyf under posisjonell forming, slik at persisk og urdu tekst rendres med riktige init / medi / fina / isol-former i enhver konsumentleser

Arabic Extended-A + Supplement (v2.119.52, v2.119.56): tabellen for koblingsklasse dekker nå de gjenværende Arabic Extended-A-tegnene (ALEF WASLA / NOON GHUNNA / HEH-varianter), Arabic Supplement U+0750-U+077F og det høyere Arabic Extended-A-området U+08A0-U+08FF. Tegn med en statisk presentasjonsformer-A-koding mappes gjennom den eksisterende 4-posisjoners formingsmotoren; tegn uten slik koding (det meste av Extended-A) får bare koblingsklasseklassifisering slik at naboene formes riktig selv når selve tegnet sendes gjennom uendret. v2.119.56 rettet to feil presentasjonsformer-A-tilordninger som ble introdusert av v2.119.52 (U+06C2 / U+06C3)

Full dekning av Persian / Urdu Form-B (v2.119.57): tabellen for koblingsklasse ble utvidet til å dekke hele U+0672-U+06D5-området (omtrent 80 tegn som dekker varianter av REH / DAL / SEEN / SAD / TAH / AIN / FEH / QAF / KAF / GAF / LAM / NOON / HEH / WAW / YEH), og 26 nye mappinger til presentasjonsformer-A ble lagt til (15 D-klasse med 4 former + 11 R-klasse med 2 former). Særlig er urdus standard 'h' HEH DOACHASHMEE (U+06BE → FBAA-FBAD) og urdus ordfinale yeh YEH BARREE (U+06D2 → FBAE-FBAF) nå riktig mappet til presentasjonsformer-A-plassene som ble feilbrukt av den midlertidige rettingen for v2.119.52 ALEF WASLA / NOON GHUNNA. Statisk presentasjonsformer-A-dekning omfatter nå mer enn 40 kildetegn

Post-pass for YEH-HAMZA + vokalligatur (v2.119.58): en post-pass lagt til _ApplyArabicShaping etter posisjonell forming dekker de 8 ligaturparene i presentasjonsformer-A-blokken U+FBEA-U+FBFB - YEH-HAMZA + ALEF / AE / WAW / U / OE / YU / E / ALEF MAKSURA. Hvert par sender ut den isolerte formen (FBEA / FBEC / FBEE / FBF0 / FBF2 / FBF4 / FBF6 / FBF9) pluss basis+1-finalformen. Start- / medialformplassene FBF8 / FBFB overlates til GSUB-motoren via sfArabicGSUB-opt-in. Bygd på samme skjelett som v2.119.32 LAM-ALEF

Allah-ligatur (v2.119.60): tegnsekvensen på fire tegn ALEF + LAM + LAM + HEH foldes til U+FDF2 ARABIC LIGATURE ALLAH ISOLATED FORM. Implementert som en statisk post-pass på kodepunktnivå etter v2.119.32 LAM-ALEF og v2.119.58 YEH-HAMZA i kjeden _ApplyArabicShaping

Bismillah-frase-ligatur (v2.119.62): den standardiserte Bismillah-frasen på 22 kodepunkter "بسم الله الرحمن الرحيم" foldes til én glyf U+FDFD ARABIC LIGATURE BISMILLAH AR-RAHMAN AR-RAHEEM. Kjøres som den aller første forbehandlingssteg i _ApplyArabicShaping (før LAM-ALEF), slik at den foldede Bismillah-glyfen når resten av pipelinen som ett kodepunkt og ikke berøres av nedstrøms substitusjoner

Offentlige oppslagshjelpere

GetArabicJoiningClass returnerer Unicode-koblingsklassen brukt av den statiske arabiske formingsmotoren. GetArabicPosition løser ett tegn i en sekvens til isolert, innledende, medial eller final posisjon slik at kallere kan inspisere eller speile de samme formingsbeslutningene før tekst sendes ut

Hvordan kallere bruker det

Formingspipelinen kjører automatisk inne i metodene for utsending av Unicode-tekst - det kreves ikke noe eksplisitt "shape this"-kall. Send Unicode-inngangsstrenger for arabisk / persisk / urdu til THPDFPage.UnicodeTextOut eller THPDFPage.RtLTextOut, og HotPDF mapper hvert inndata-kodepunkt til sin presentasjonsform før PDF-tekstoperatoren skrives. De opprinnelige Unicode-bytene fanges også i FUnicodeUsedCps for generering av ToUnicode CMap, slik at kopier / lim inn på lesersiden og skjermlesere fortsatt ser den opprinnelige Unicode-lasten

Fontkrav

Fonten som registreres via RegisterUnicodeTTF må inneholde glyfer for både arabiske presentasjonsformer-B-blokken (U+FE70 - U+FEFC) og (for persisk / urdu) det relevante området i arabiske presentasjonsformer-A (U+FB50 - U+FDFF). Anbefalte fonter som leverer hele settet:

Noto Sans Arabic (latin + arabisk; presentasjonsformer-A + presentasjonsformer-B + Arabic Extended-A)

Noto Naskh Arabic, Noto Naskh Arabic UI

Amiri (tradisjonell Naskh, full dekning av presentasjonsformer-A + presentasjonsformer-B)

Scheherazade New (SIL, laget for språk i den muslimske verden)

Microsoft Arabic Typesetting / Tahoma / Times New Roman (medfølger i Windows, full presentasjonsformer-B; noen har presentasjonsformer-A-dekning)

Når den registrerte fonten mangler en glyf for en avledet presentasjonsform, faller HotPDF tilbake til base-Unicode-kodepunktet og sender det ut uendret; konsumentlesere kan da forsøke egen forming (Acrobat, Foxit) eller rendere .notdef

Typisk arbeidsflyt

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;

Automatisk Fase 8-pipelineintegrasjon (v2.119.59 - v2.119.68)

v2.119.59 introduserte den valgfrie egenskapen ShapingFeatures: THPDFShapingFeatures og enumerasjonen THPDFShapingFeature, som løfter formingspipelinen utover statisk post-pass-folding til automatisk GSUB-drevet fontspefikksubstitusjon. Sett PDF.ShapingFeatures := [sfArabicGSUB] for å bruke fontens egne arabiske init, medi, fina, isol, rlig, calt og rclt-oppslag og sende ut de resulterende kontekstuelle glyf-ID-ene; legg til sfCursiveAttachment for å bruke GPOS-kursive inn-/utgangsankre på den formede sekvensen; legg til sfStandardLigatures for latinske standardligaturer (FB00-FB06 ff / fi / fl / ffi / ffl / ſt / st via v2.119.65 ApplyLatinLigatureRefinement); legg til sfIndicShaping for å aktivere devanagari-prepass-omleggingen (v2.119.67). Standard [] bevarer byte-identisk utdata for kallere som er avhengige av den statiske pipelinen

Når sfArabicGSUB er satt, omgås den statiske Unicode-presentasjonsformsmotoren til fordel for fontens egne GSUB-regler. HotPDF sender ut native kontekstuelle glyf-ID-er gjennom syntetiske kodepunkter når disse glyfene ikke kan nås fra fontens cmap, holder det innebygde utvalget lukket og skriver ToUnicode-reverse-mappinger for kopiering og liming. Kallere som vil at den statiske formingsmotoren skal fortsette å kjøre for kodepunktsdekning utover det fontens GSUB deklarerer, bør la sfArabicGSUB stå av og stole på den statiske post-pass-kjeden

Tilbakekobling av ligaturer i ToUnicode CMap (v2.119.61, v2.119.62, v2.119.65)

Adobe-Identity-UCS ToUnicode CMap sendt ut av RegisterUnicodeTTF leverer bfchar-reverse-mapping-oppføringer for hvert ligaturkodepunkt som post-pass-kjeden kan produsere. v2.119.61 la til 27 oppføringer (8 LAM-ALEF + 18 YEH-HAMZA-familien + 1 Allah); v2.119.62 la til Bismillah (U+FDFD); v2.119.65 la til 7 oppføringer for latinske standardligaturer (FB00-FB06). Kopier / lim inn på lesersiden løser enhver ligaturglyf tilbake til kildesekvensen av kodepunkter, slik at den rendrerte PDF-en forblir tilgjengelighetsvennlig

Syntetisk kodepunktutskrift fra PUA (v2.119.68)

AssignSyntheticCodepointForGID(GID; out CP): Boolean + GetSyntheticCodepointForGID(GID): Word lar produksjonskoden sende ut GSUB-erstatnings-GID-er som ikke har noe naturlig Unicode-kodepunkt tilgjengelig gjennom fontens cmap. Allokatoren deler ut kodepunkter i Private Use Area (U+E000 - U+F8FF, 6400 plasser) og speiler tildelingen inn i FUnicodeCpToGid (slik at /CIDToGIDMap løser det syntetiske CP-et tilbake til målet-GID hos konsumentleseren), FAcroFormUnicodeAdvances (slik at v2.65-ordombryting finner riktig em-fraksjon), og en reverse-oppslagstabell per GID (slik at gjentatte tildelingsforespørsler er idempotente). Bruk dette for devanagari-klaseformer, stilistiske alternativer og CJK-ideografiske variasjonssekvenser som GSUB introduserer, men cmap ikke når

Forholdet til OpenType GSUB-motoren

Den statiske post-pass-formingsmotoren beskrevet over (v2.85.0 + v2.119.32 / 58 / 60 / 62) er som standard uavhengig av OpenType GSUB-motoren. Når sfArabicGSUB aktiveres gjennom ShapingFeatures, blir GSUB-motoren en del av produksjonssiden for utsending: HotPDF spør cmap for å bygge en grunnleggende GID-tabell, bruker de innebygde arabiske posisjons- og kontekstuelle GSUB-oppslagene på glyfsekvensen, tildeler syntetiske kodepunkter for erstatnings-GID-er som ikke har noen Unicode-presentasjonsform, og kaller MarkUnicodeGlyphUsed for å holde erstatningsglyfene innenfor det innebygde fontutvalget

For erstatningsglyfer uten Unicode-kodepunkt kombinerer kallere ShapingFeatures med v2.119.68s PUA-syntetiske kodepunkts-allokator slik at erstatnings-GID-en fortsatt kan nås gjennom den vanlige hex-pipelinen. Den statiske post-pass-kjeden forblir standard fallback for kodepunkter som fontens GSUB-deklarasjoner ikke dekker

Omfang og begrensninger

BiDi-algoritmen ligger fortsatt utenfor denne siden: kallere må fremdeles ordne blandede LTR- og RTL-sekvenser selv eller bruke et separat BiDi-bibliotek. Støtte for GPOS, Indic/Tibetan/Mongolian, hebraisk, N'Ko, Adlam, Thai/Lao og Javanesisk ligger nå på egne opt-in-formingsflagg- og API-sider, så denne siden fokuserer bare på statisk og GSUB-basert arabisk forming

Se også: OpenType GSUB-erstatningsmotor, Automatisk formings-pipeline (fase 8), Støtte for syrisk / mongolsk / devanagari-forming, THotPDF.AssignSyntheticCodepointForGID, THPDFPage.RtLTextOut, THPDFPage.UnicodeTextOut, CFF / OpenType-fontunderinndeling