Arab / perzsa / urdu formázás támogatása

Előállító-oldali formázási csővezeték (v2.85.0 - v2.119.68)

A HotPDF egy előállító-oldali formázási pipeline-t futtat, amely a Unicode-bemenetű arab, perzsa és urdu futamokat az arab bemutatási formáikba (Arabic Presentation Forms) hajtja össze a PDF szövegkibocsátás során, így a felhasználói olvasók készre renderelhető pozicionális / ligatúra glifákat kapnak anélkül, hogy saját Harfbuzz-osztályú formázóra lenne szükségük

Mit csinál a pipeline

Pozicionális formázás (v2.85.0): minden arab betűnek legfeljebb négy pozicionális formája van - izolált (isol), kezdeti (init), mediális (medi) és végső (fina). A HotPDF megvizsgálja minden egyes arab karakter kapcsolódási osztályát és a közvetlen szomszédai kapcsolódási osztályait, majd leképezi a bemeneti kódpontot a megfelelő arab bemutatási formák-B (Arabic Presentation Forms-B) (U+FE70 - U+FEFC) glifára a kibocsátás előtt. A nem kapcsolódó betűk, kapcsolók, transzparens karakterek (kombináló jelek) és a Tatweel kashida kezelése mind a Unicode arab formázási algoritmus szerint történik

Kötelező LAM-ALEF ligatúra (v2.119.32): az arab Unicode formázási specifikáció előírja, hogy minden olyan LAM (U+0644) karaktert, amelyet közvetlenül egy ALEF követ (U+0627 sima, U+0622 madda-val felül, U+0623 hamza-val felül, U+0625 hamza-val alul), egyetlen ligatúra glifába (U+FEFB - U+FEFC izolált / végső formák a megfelelő hamza / madda variánsokkal) kell összevonni. Ez az arab tipográfia azon kevés nem választható ligatúráinak egyike, amely a helyességhez szükséges; különálló glifákként történő renderelésük olyan szöveget eredményez, amelyet az anyanyelvi olvasók azonnal hibásnak ismernek fel. A HotPDF végrehajtja az összevonást a kibocsátás során, így a hívóknak nincs szükségük Harfbuzz-osztályú formázóra a saját kódútvonalukon

Perzsa / urdu alapvető 9 betű (v2.119.35): a perzsa és az urdu olyan betűkkel egészíti ki az arabot, amelyek nincsenek benne az arab bemutatási formák-B (Arabic Presentation Forms-B) blokkban (U+FE70 - U+FEFC). A 9 leggyakrabban használt ilyen betű – beleértve a 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) és HEH GOAL (U+06C1) karaktereket – az arab bemutatási formák-A (Arabic Presentation Forms-A) (U+FB50 - U+FDFF) blokkban rendelkezik bemutatási formákkal. A HotPDF most már leképezi ezeket a betűket a megfelelő Forms-A glifára a pozicionális formázás során, így a perzsa és urdu szöveg a megfelelő init / medi / fina / isol formákkal renderelődik bármely felhasználói olvasóban

Arab Extended-A + Supplement (v2.119.52, v2.119.56): a kapcsolódási osztály táblázata most már lefedi a fennmaradó arab Extended-A karaktereket (ALEF WASLA / NOON GHUNNA / HEH variánsok), az arab Supplement U+0750-U+077F és a magasabb arab Extended-A U+08A0-U+08FF tartományt. A statikus Presentation Forms-A kódolással rendelkező karakterek leképezése a meglévő 4 pozíciós formázón keresztül történik; a kódolás nélküliek (az Extended-A nagy része) csak kapcsolódási osztály besorolást kapnak, így a szomszédok helyesen formázódnak akkor is, ha maga a karakter változatlanul halad át. A v2.119.56 verzió javított két hibás Forms-A leképezést, amelyeket a v2.119.52 vezetett be (U+06C2 / U+06C3)

Perzsa / urdu Form-B teljes lefedettség (v2.119.57): a kapcsolódási osztály táblázatot kiterjesztettük a teljes U+0672-U+06D5 tartományra (körülbelül 80 karakter, amely lefedi a REH / DAL / SEEN / SAD / TAH / AIN / FEH / QAF / KAF / GAF / LAM / NOON / HEH / WAW / YEH variánsokat), és 26 új Presentation Forms-A leképezést adtunk hozzá (15 D-osztályú 4-formájú + 11 R-osztályú 2-formájú). Nevezetesen az urdu szabványos 'h' HEH DOACHASHMEE (U+06BE → FBAA-FBAD) és az urdu szóvégi yeh YEH BARREE (U+06D2 → FBAE-FBAF) most már helyesen van leképezve a Forms-A helyekre, amelyeket a v2.119.52 ALEF WASLA / NOON GHUNNA ideiglenes javítása helytelenül használt. A statikus Forms-A lefedettség immár 40+ forráskarakterre terjed ki

YEH-HAMZA + magánhangzó ligatúra utólagos menet (v2.119.58): az _ApplyArabicShaping-hoz a pozicionális formázás után hozzáadott utólagos menet (post-pass) lefedi a 8 ligatúrapárt az U+FBEA-U+FBFB Forms-A blokkban - YEH-HAMZA + ALEF / AE / WAW / U / OE / YU / E / ALEF MAKSURA. Mindegyik pár kibocsátja az izolált formát (FBEA / FBEC / FBEE / FBF0 / FBF2 / FBF4 / FBF6 / FBF9), plusz az alap+1 végső formát. A kezdő / mediális formahelyek FBF8 / FBFB a GSUB motorra vannak bízva a sfArabicGSUB opt-in-en keresztül. A v2.119.32 LAM-ALEF megegyező vázára épül

Allah ligatúra (v2.119.60): a négykarakteres ALEF + LAM + LAM + HEH sorozat összevonódik az U+FDF2 ARABIC LIGATURE ALLAH ISOLATED FORM karakterbe. Kódpontszintű statikus utólagos menetként valósult meg a v2.119.32 LAM-ALEF and a v2.119.58 YEH-HAMZA után az _ApplyArabicShaping láncban

Bismillah kifejezés ligatúra (v2.119.62): a szabványos 22 kódpontos Bismillah kifejezés "بسم الله الرحمن الرحيم" egyetlen glifába (U+FDFD ARABIC LIGATURE BISMILLAH AR-RAHMAN AR-RAHEEM) vonódik össze. Az _ApplyArabicShaping-ban a legelső előzetes menetként (pre-pass) fut (a LAM-ALEF előtt), így az összevont Bismillah glifa egyetlen kódpontként éri el a pipeline többi részét, és a későbbi helyettesítések nem érintik újra

Nyilvános lekérdező segédek

A GetArabicJoiningClass visszaadja a statikus arab formázó által használt Unicode kapcsolódási osztályt. A GetArabicPosition felold egy futamban lévő karaktert izolált, kezdeti, mediális vagy végső pozícióra, így a hívók megvizsgálhatják vagy tükrözhetik ugyanazokat a formázási döntéseket a szöveg kibocsátása előtt

Hogyan hívják meg a hívók

A formázási pipeline automatikusan fut a Unicode szövegkibocsátási metódusokon belül – nincs szükség explicit "shape this" hívásra. Adjon át Unicode-bemenetű arab / perzsa / urdu karakterláncokat a THPDFPage.UnicodeTextOut vagy THPDFPage.RtLTextOut metódusnak, és a HotPDF leképezi az egyes bemeneti kódpontokat a bemutatási formájukra a PDF szövegmegjelenítő operátor kiírása előtt. Az eredeti Unicode bájtok szintén rögzítésre kerülnek az FUnicodeUsedCps-ben a ToUnicode CMap generáláshoz, így a felhasználói oldali másolás / beillesztés és a képernyőolvasók továbbra is az eredeti Unicode adatokat látják

Betűtípus követelmények

A RegisterUnicodeTTF-en keresztül regisztrált betűtípusnak tartalmaznia kell a glifákat mind az arab bemutatási formák-B (Arabic Presentation Forms-B) blokkhoz (U+FE70 - U+FEFC), mind (perzsa / urdu esetén) a vonatkozó arab bemutatási formák-A (Arabic Presentation Forms-A) tartományhoz (U+FB50 - U+FDFF). A teljes készletet tartalmazó ajánlott betűtípusok:

Noto Sans Arabic (latin + arab; Forms-A + Forms-B + Arabic Extended-A)

Noto Naskh Arabic, Noto Naskh Arabic UI

Amiri (hagyományos Naskh, teljes Forms-A + Forms-B lefedettség)

Scheherazade New (SIL, a muszlim világ nyelveihez tervezve)

Microsoft Arabic Typesetting / Tahoma / Times New Roman (Windows-hoz mellékelt, teljes Forms-B; néhány rendelkezik Forms-A lefedettséggel)

Ha a regisztrált betűtípusból hiányzik a glifa egy származtatott bemutatási formához, a HotPDF visszaesik az alap Unicode kódpontra és változatlanul bocsátja ki azt; a felhasználói olvasók ezután megkísérelhetik a saját formázásukat (Acrobat, Foxit) vagy a .notdef renderelését

Tipikus munkafolyamat

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;

Automatikus Phase 8 pipeline integráció (v2.119.59 - v2.119.68)

A v2.119.59 bevezette az opcionális (opt-in) ShapingFeatures: THPDFShapingFeatures tulajdonságot és a THPDFShapingFeature enumot, amely a formázási pipeline-t a statikus utólagos összevonáson túl automatikus, GSUB-vezérelt, betűtípus-specifikus helyettesítéssé emeli. Állítsa be a PDF.ShapingFeatures := [sfArabicGSUB] értéket a regisztrált betűtípus natív arab init, medi, fina, isol, rlig, calt és rclt kereséseinek alkalmazásához és a kapott kontextuális glifa-azonosítók kibocsátásához; adja hozzá a sfCursiveAttachment-et a GPOS kurzív belépési/kilépési horgonyok alkalmazásához a formázott futamon; adja hozzá a sfStandardLigatures-t a latin standard ligatúrákhoz (FB00-FB06 ff / fi / fl / ffi / ffl / ſt / st a v2.119.65 ApplyLatinLigatureRefinement-en keresztül); adja hozzá a sfIndicShaping-ot a devanagari előzetes menetbeli újrarendezés (v2.119.67) engedélyezéséhez. Az alapértelmezett [] megőrzi a bájt-azonos kimenetet a statikus pipeline-tól függő hívók számára

Ha a sfArabicGSUB be van állítva, a statikus Unicode Presentation Forms formázó megkerülésre kerül a betűtípus saját GSUB szabályai javára. A HotPDF natív kontextuális glifa-azonosítókat bocsát ki szintetikus kódpontokon keresztül, ha ezek a glifák nem érhetők el a betűtípus cmap-jából, zártan tartja a beágyazott részhalmazt, és ToUnicode fordított leképezéseket ír a másoláshoz és beillesztéshez. Azok a hívók, akik azt szeretnék, hogy a statikus formázó továbbra is fusson a betűtípus GSUB nyilatkozatán kívüli kódpontok lefedettségére, hagyják kikapcsolva a sfArabicGSUB-ot, és hagyatkozzanak a statikus utólagos menetláncra

ToUnicode CMap ligatúra fordított leképezés (v2.119.61, v2.119.62, v2.119.65)

A RegisterUnicodeTTF által kibocsátott Adobe-Identity-UCS ToUnicode CMap tartalmaz bfchar fordított leképezési bejegyzéseket minden olyan ligatúra-kódponthoz, amelyet az utólagos menetlánc előállíthat. A v2.119.61 verzió 27 bejegyzést adott hozzá (8 LAM-ALEF + 18 YEH-HAMZA család + 1 Allah); a v2.119.62 hozzáadta a Bismillah-t (U+FDFD); a v2.119.65 hozzáadott 7 Latin Standard Ligature bejegyzést (FB00-FB06). A felhasználói olvasó másolása / beillesztése feloldja a ligatúra glifákat a forrás kódpontsorozattá, így a renderelt PDF akadálymentes marad

PUA szintetikus kódpont kibocsátás (v2.119.68)

Az AssignSyntheticCodepointForGID(GID; out CP): Boolean + GetSyntheticCodepointForGID(GID): Word lehetővé teszi a kibocsátó kód számára olyan GSUB helyettesítő GID-ek kibocsátását, amelyek nem rendelkeznek természetes Unicode kódponttal a betűtípus cmap-jén keresztül. Az allokátor a Private Use Area (magáncélú terület) (U+E000 - U+F8FF, 6400 hely) kódpontjait osztja ki, és tükrözi a hozzárendelést az FUnicodeCpToGid-be (így a /CIDToGIDMap feloldja a szintetikus kódpontot a cél GID-re a felhasználó olvasónál), az FAcroFormUnicodeAdvances-be (így a v2.65-ös sortörés megtalálja a megfelelő em-töredéket) és egy GID-enkénti fordított keresési táblázatba (így az ismételt hozzárendelési kérelmek idempotensek). Használja ezt devanagari klaszterformákhoz, stilisztikai alternatívákhoz és CJK ideográfiai variációs sorozatokhoz, amelyeket a GSUB bevezet, de a cmap nem ér el

Kapcsolat az OpenType GSUB motorral

A fent leírt statikus utólagos menetformázó (v2.85.0 + v2.119.32 / 58 / 60 / 62) alapértelmezés szerint független az OpenType GSUB motortól. Ha a sfArabicGSUB engedélyezve van a ShapingFeatures tulajdonságon keresztül, a GSUB motor az előállító-oldali kibocsátási útvonal részévé válik: a HotPDF lekérdezi a cmap-ot egy alap GID tömb felépítéséhez, natív arab pozicionális és kontextuális GSUB kereséseket alkalmaz az adott glifafutamon, szintetikus kódpontokat rendel hozzá az olyan helyettesítő glifa-azonosítókhoz (GID), amelyek nem rendelkeznek Unicode Presentation Form kódponttal, és meghívja a MarkUnicodeGlyphUsed metódust a helyettesítő glifák beágyazott betűtípus-részhalmazban való tartásához

A Unicode kódpont nélküli helyettesítő glifák esetén a hívók kombinálják a ShapingFeatures-t a v2.119.68-as PUA szintetikus-kódpont allokátorral, így a helyettesítő GID továbbra is elérhető a szabványos hexadecimális pipeline-on keresztül. A statikus utólagos menetlánc marad az alapértelmezett tartalék megoldás a betűtípus GSUB deklarációi által nem lefedett kódpontokhoz

Hatókör és korlátozások

A BiDi algoritmus ezen az oldalon kívül marad: a hívóknak továbbra is maguknak kell rendezniük a vegyes LTR és RTL futamokat, vagy egy külön BiDi könyvtárat kell használniuk. A GPOS, Indic/Tibetan/Mongolian, héber, N'Ko, Adlam, thai/laoszi és jávai nyelvek támogatása most külön opt-in formázási flag és API oldalakon található, így ez az oldal csak a statikus és GSUB-alapú arab formázásra összpontosít

Lásd még: OpenType GSUB Substitution Engine, Automatic Shaping Pipeline (Phase 8), Syriac / Mongolian / Devanagari Shaping, THotPDF.AssignSyntheticCodepointForGID, THPDFPage.RtLTextOut, THPDFPage.UnicodeTextOut, CFF / OpenType Font Subsetting