Arabic / Persian / Urdu Shaping – podpora

Pipeline tvarování na straně producenta (v2.85.0 - v2.119.68)

HotPDF spouští pipeline tvarování na straně producenta, která při emitování textu PDF převádí vstupní arabské, perské a urdské běhy Unicode na jejich Arabic Presentation Forms, takže čtečky dokumentů dostanou poziční a ligaturní glyfy připravené k vykreslení bez vlastního shaperu třídy Harfbuzz

Co pipeline dělá

Poziční tvarování (v2.85.0): každé základní arabské písmeno má až čtyři poziční tvary - izolovaný (isol), počáteční (init), středový (medi) a koncový (fina). HotPDF zkontroluje spojovací třídu každého arabského znaku a spojovací třídy jeho bezprostředních sousedů a před emitováním namapuje vstupní codepoint na odpovídající glyph Arabic Presentation Forms-B (U+FE70 - U+FEFC). Nespojující písmena, joinery, transparentní znaky (kombinační značky) i Tatweel kashida se zpracují podle algoritmu Unicode Arabic Shaping

Povinná ligatura LAM-ALEF (v2.119.32): specifikace Arabic Unicode Shaping vyžaduje, aby se libovolné LAM (U+0644) bezprostředně následované ALEF (prosté U+0627, U+0622 s madda nahoře, U+0623 s hamza nahoře, U+0625 s hamza dole) složilo do jednoho ligaturního glyphu (izolované / koncové tvary U+FEFB - U+FEFC s odpovídajícími variantami hamza / madda). Je to jedna z mála nepovinně nevypnutelných ligatur arabské typografie a je nutná pro správnost; vykreslení jako samostatné glyfy vytvoří text, který rodilí čtenáři okamžitě rozpoznají jako chybný. HotPDF provede složení během emise, takže volající ve své kódové cestě nepotřebují shaper třídy Harfbuzz

9 základních perských / urdských písmen (v2.119.35): perština a urdština rozšiřují arabštinu o písmena, která nejsou v bloku Arabic Presentation Forms-B (U+FE70 - U+FEFC). Devět nejpoužívanějších z těchto písmen - včetně 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í tvary v Arabic Presentation Forms-A (U+FB50 - U+FDFF). HotPDF nyní během pozičního tvarování mapuje tato písmena na odpovídající glyph Forms-A, takže se perský a urdský text v libovolné čtečce vykreslí se správnými tvary init / medi / fina / isol

Arabic Extended-A + Supplement (v2.119.52, v2.119.56): tabulka spojovacích tříd nyní pokrývá zbývající znaky Arabic Extended-A (varianty ALEF WASLA / NOON GHUNNA / HEH), Arabic Supplement U+0750-U+077F a vyšší rozsah Arabic Extended-A U+08A0-U+08FF. Znaky se statickým kódováním Presentation Forms-A se mapují přes existující čtyřpoziční shaper; znaky bez něj (většina Extended-A) dostanou jen klasifikaci spojovací třídy, aby se sousedé tvarovali správně i v případě, že samotný znak projde beze změny. v2.119.56 opravila dvě chybná mapování Forms-A zavedená verzí v2.119.52 (U+06C2 / U+06C3)

Plné pokrytí Persian / Urdu Form-B (v2.119.57): tabulka spojovacích tříd byla rozšířena na celý rozsah U+0672-U+06D5 (přibližně 80 znaků pokrývajících varianty REH / DAL / SEEN / SAD / TAH / AIN / FEH / QAF / KAF / GAF / LAM / NOON / HEH / WAW / YEH) a bylo přidáno 26 nových mapování Presentation Forms-A (15 čtyřtvarových tříd D + 11 dvoutvarových tříd R). Zejména standardní urdské 'h' HEH DOACHASHMEE (U+06BE → FBAA-FBAD) a urdské slovně koncové yeh YEH BARREE (U+06D2 → FBAE-FBAF) jsou nyní správně mapované do slotů Forms-A, které dočasná oprava ALEF WASLA / NOON GHUNNA ve v2.119.52 použila chybně. Statické pokrytí Forms-A nyní zahrnuje 40+ zdrojových znaků

Post-pass ligatur YEH-HAMZA + samohláska (v2.119.58): post-pass přidaný do _ApplyArabicShaping po pozičním tvarování pokrývá 8 párů ligatur v bloku Forms-A U+FBEA-U+FBFB - YEH-HAMZA + ALEF / AE / WAW / U / OE / YU / E / ALEF MAKSURA. Každý pár emituje izolovaný tvar (FBEA / FBEC / FBEE / FBF0 / FBF2 / FBF4 / FBF6 / FBF9) plus koncový tvar base+1. Sloty počátečního / středového tvaru FBF8 / FBFB jsou ponechány GSUB enginu přes opt-in sfArabicGSUB. Postaveno na stejném skeletu jako v2.119.32 LAM-ALEF

Ligatura Allah (v2.119.60): čtyřznaková sekvence ALEF + LAM + LAM + HEH se složí do U+FDF2 ARABIC LIGATURE ALLAH ISOLATED FORM. Implementováno jako statický post-pass na úrovni codepointů po v2.119.32 LAM-ALEF a v2.119.58 YEH-HAMZA v řetězci _ApplyArabicShaping

Ligatura fráze Bismillah (v2.119.62): standardní 22codepointová fráze Bismillah "بسم الله الرحمن الرحيم" se složí do jednoho glyphu U+FDFD ARABIC LIGATURE BISMILLAH AR-RAHMAN AR-RAHEEM. Běží jako úplně první pre-pass v _ApplyArabicShaping (před LAM-ALEF), takže složený glyph Bismillah dorazí do zbytku pipeline jako jeden codepoint a downstream substituce se ho už znovu nedotknou

Veřejné dotazovací pomocné funkce

GetArabicJoiningClass vrací spojovací třídu Unicode používanou statickým arabským shaperem. GetArabicPosition vyhodnotí jeden znak v běhu na izolovanou, počáteční, středovou nebo koncovou pozici, aby volající mohli před emitováním textu zkontrolovat nebo zrcadlit stejná rozhodnutí o tvarování

Jak ji volající spustí

Pipeline tvarování běží automaticky uvnitř metod emise textu Unicode - není potřeba žádné explicitní volání "shape this". Předejte arabské / perské / urdské řetězce ve vstupu Unicode metodě THPDFPage.UnicodeTextOut nebo THPDFPage.RtLTextOut a HotPDF před zápisem operátoru PDF pro zobrazení textu namapuje každý vstupní codepoint na jeho prezentační tvar. Původní bajty Unicode se také zachytí do FUnicodeUsedCps pro generování ToUnicode CMap, takže kopírování / vložení na straně čtečky a čtečky obrazovky stále vidí původní Unicode payload

Požadavky na font

Font registrovaný přes RegisterUnicodeTTF musí obsahovat glyfy pro blok Arabic Presentation Forms-B (U+FE70 - U+FEFC) a pro perštinu / urdštinu také příslušný rozsah Arabic Presentation Forms-A (U+FB50 - U+FDFF). Doporučené fonty dodávané s úplnou sadou:

Noto Sans Arabic (latinka + arabština; Forms-A + Forms-B + Arabic Extended-A)

Noto Naskh Arabic, Noto Naskh Arabic UI

Amiri (tradiční Naskh, úplné pokrytí Forms-A + Forms-B)

Scheherazade New (SIL, navržené pro jazyky muslimského světa)

Microsoft Arabic Typesetting / Tahoma / Times New Roman (součást Windows, úplné Forms-B; některé mají pokrytí Forms-A)

Když registrovanému fontu chybí glyph pro odvozený prezentační tvar, HotPDF se vrátí k základnímu Unicode codepointu a emituje jej beze změny; čtečky dokumentů se pak mohou pokusit o vlastní tvarování (Acrobat, Foxit) nebo vykreslit .notdef

Typický pracovní postup

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;

Automatická integrace pipeline Phase 8 (v2.119.59 - v2.119.68)

v2.119.59 zavedla opt-in vlastnost ShapingFeatures: THPDFShapingFeatures a výčet THPDFShapingFeature, které posouvají pipeline tvarování za statické post-pass skládání do automatické fontově specifické substituce řízené GSUB. Nastavte PDF.ShapingFeatures := [sfArabicGSUB], aby se použily nativní arabské lookupy registrovaného fontu init, medi, fina, isol, rlig, calt a rclt a emitovala výsledná kontextová ID glyphů; přidejte sfCursiveAttachment pro aplikaci vstupních/výstupních kurzivních anchorů GPOS na tento vytvarovaný běh; přidejte sfStandardLigatures pro latinské Standard Ligatures (FB00-FB06 ff / fi / fl / ffi / ffl / ſt / st přes v2.119.65 ApplyLatinLigatureRefinement); přidejte sfIndicShaping pro zapnutí reorder pre-passu Devanagari (v2.119.67). Výchozí [] zachovává bajtově identický výstup pro volající, kteří závisejí na statické pipeline

Když je nastaveno sfArabicGSUB, statický shaper Unicode Presentation Forms se obejde ve prospěch vlastních pravidel GSUB fontu. HotPDF emituje nativní kontextová ID glyphů přes syntetické codepointy, pokud tyto glyfy nejsou dosažitelné z font cmap, udržuje vložený subset uzavřený a zapisuje reverzní mapování ToUnicode pro kopírování a vložení. Volající, kteří chtějí, aby statický shaper dál běžel pro pokrytí codepointů mimo deklarace GSUB fontu, by měli nechat sfArabicGSUB vypnuté a spoléhat na statický post-pass řetězec

Reverzní mapování ligatur v ToUnicode CMap (v2.119.61, v2.119.62, v2.119.65)

Adobe-Identity-UCS ToUnicode CMap emitovaná metodou RegisterUnicodeTTF obsahuje reverzní mapovací položky bfchar pro každý ligaturní codepoint, který může post-pass řetězec vytvořit. v2.119.61 přidala 27 položek (8 LAM-ALEF + 18 z rodiny YEH-HAMZA + 1 Allah); v2.119.62 přidala Bismillah (U+FDFD); v2.119.65 přidala 7 položek Latin Standard Ligature (FB00-FB06). Kopírování / vložení ve čtečce dokumentů převede libovolný ligaturní glyph zpět na zdrojovou sekvenci codepointů, takže vykreslené PDF zůstává přístupné

Emise syntetických codepointů PUA (v2.119.68)

AssignSyntheticCodepointForGID(GID; out CP): Boolean + GetSyntheticCodepointForGID(GID): Word umožňují producentskému kódu emitovat náhradní GSUB GID, která nemají přirozený Unicode codepoint dosažitelný přes cmap fontu. Alokátor přiděluje codepointy v Private Use Area (U+E000 - U+F8FF, 6400 slotů) a zrcadlí přiřazení do FUnicodeCpToGid (aby /CIDToGIDMap ve čtečce dokumentů vyřešil syntetický CP zpět na cílové GID), FAcroFormUnicodeAdvances (aby word-wrap z v2.65 našel správný em-fraction) a reverzní vyhledávací tabulky po GID (aby opakované žádosti o přiřazení byly idempotentní). Použijte to pro tvary clusterů Devanagari, stylistické alternativy a CJK ideografické variační sekvence, které GSUB zavádí, ale cmap je nedosáhne

Vztah k enginu OpenType GSUB

Výše popsaný statický post-pass shaper (v2.85.0 + v2.119.32 / 58 / 60 / 62) je ve výchozím nastavení nezávislý na enginu OpenType GSUB. Když je sfArabicGSUB zapnuto přes ShapingFeatures, GSUB engine se stane součástí emisní cesty na straně producenta: HotPDF použije cmap k sestavení základního pole GID, aplikuje nativní arabské poziční a kontextové GSUB lookupy na tento běh glyphů, přiřadí syntetické codepointy pro náhradní ID glyphů, která nemají Unicode Presentation Form, a zavolá MarkUnicodeGlyphUsed, aby náhradní glyfy zůstaly ve vloženém subsetu fontu

Pro náhradní glyfy bez Unicode codepointu volající zkombinují ShapingFeatures s alokátorem syntetických codepointů PUA z v2.119.68, aby náhradní GID zůstalo dosažitelné přes standardní hex pipeline. Statický post-pass řetězec zůstává výchozím fallbackem pro codepointy, které deklarace GSUB ve fontu nepokrývají

Rozsah a omezení

Algoritmus BiDi zůstává mimo tuto stránku: volající stále musí smíšené běhy LTR a RTL seřadit sami nebo použít samostatnou knihovnu BiDi. Podpora GPOS, Indic/Tibetan/Mongolian, Hebrew, N'Ko, Adlam, Thai/Lao a Javanese je nyní na samostatných stránkách opt-in flagů tvarování a API, takže tato stránka se soustředí jen na statické a GSUB arabské tvarování

Viz také: Substituční engine OpenType GSUB, Automatická pipeline tvarování (Phase 8), Tvarování Syriac / Mongolian / Devanagari, THotPDF.AssignSyntheticCodepointForGID, THPDFPage.RtLTextOut, THPDFPage.UnicodeTextOut, Subsetování fontů CFF / OpenType