Arabic / Persian / Urdu Shaping Support

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

HotPDF ajaa tuottajapuolella muotoiluputkea, joka taittaa Unicode-syötteiset arabian, persian ja urdun kielen ajot arabian esitysmuotoihin (Arabic Presentation Forms) PDF-tekstin lähetyksen aikana, jotta katseluohjelmat vastaanottavat renderöintivalmiita sijainti- / ligatuuriglyfejä tarvitsematta omaa Harfbuzz-luokan muotoilijaa

Mitä käsittelyputki tekee

Asemamuotoilu (v2.85.0): jokaisella arabialaisella peruskirjaimella on enintään neljä asemamuotoa – itsenäinen (isol), alussa oleva (init), keskellä oleva (medi) ja lopussa oleva (fina). HotPDF tarkistaa jokaisen arabialaisen merkin liitosluokan ja sen välittömien naapureiden liitosluokat ja kartoittaa sitten syötetyn koodipisteen asianmukaiseen Arabic Presentation Forms-B (U+FE70 - U+FEFC) -glyfiin ennen tulostusta. Ei-liittyvät kirjaimet, liittimet, läpinäkyvät merkit (yhdistelmämerkit) ja Tatweel kashida käsitellään kaikki Unicode Arabic Shaping -algoritmin mukaisesti

Pakollinen LAM-ALEF-ligatuuri (v2.119.32): arabian Unicode-muotoilumääritys (Arabic Unicode Shaping spec) vaatii, että mikä tahansa LAM (U+0644), jota seuraa välittömästi ALEF (U+0627 tavallinen, U+0622 madda yläpuolella, U+0623 hamza yläpuolella, U+0625 hamza alapuolella), yhdistyy yhdeksi ligatuuriglyfiksi (U+FEFB - U+FEFC itsenäiset / lopulliset muodot asianmukaisilla hamza- / madda-varianteilla). Tämä on yksi harvoista pakollisista ligatuureista arabialaisessa typografiassa ja sitä vaaditaan oikeellisuuden vuoksi; niiden renderöiminen erillisinä glyfeinä tuottaa tekstiä, jonka äidinkieliset lukijat tunnistavat heti virheelliseksi. HotPDF suorittaa yhdistämisen tulostuksen aikana, joten kutsujat eivät tarvitse Harfbuzz-luokan muotoilijaa omassa koodipolussaan

Persian / Urdu core 9 letters (v2.119.35): persia ja urdu laajentavat arabiaa kirjaimilla, joita ei ole Arabic Presentation Forms-B -lohkossa (U+FE70 - U+FEFC). Yhdeksällä eniten käytetyllä tällaisella kirjaimella – mukaan lukien 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) ja HEH GOAL (U+06C1) – on esitysmuodot Arabic Presentation Forms-A -lohkossa (U+FB50 - U+FDFF). HotPDF kartoittaa nyt nämä kirjaimet asianmukaiseen Forms-A-glyfiin asemamuotoilun aikana, jotta persian- ja urdunkielinen teksti piirtyy oikeilla init- / medi- / fina- / isol-muodoilla kaikissa lukulaitteissa

Arabic Extended-A + Supplement (v2.119.52, v2.119.56): liitosluokkataulukko (joining-class table) kattaa nyt loput arabian Extended-A-merkit (ALEF WASLA / NOON GHUNNA / HEH -variantit), Arabic Supplement U+0750-U+077F -alueen ja ylemmän arabian Extended-A U+08A0-U+08FF -alueen. Merkit, joilla on staattinen Presentation Forms-A -koodaus, kartoitetaan olemassa olevan 4-asentoisen muotoilijan kautta; merkit ilman sitä (suurin osa Extended-A:sta) saavat vain liitosluokkakohdistuksen, jotta naapurit muotoillaan oikein silloinkin, kun itse merkki välitetään muuttumattomana. Versio v2.119.56 korjasi kaksi virheellistä Forms-A-kartoitusta, jotka versio v2.119.52 toi mukanaan (U+06C2 / U+06C3)

Persian / Urdu Form-B full coverage (v2.119.57): liitostyyppitaulukkoa (joining-class table) laajennettiin kattamaan koko alue U+0672-U+06D5 (noin 80 merkkiä, jotka kattavat REH / DAL / SEEN / SAD / TAH / AIN / FEH / QAF / KAF / GAF / LAM / NOON / HEH / WAW / YEH -variantit), ja 26 uutta Presentation Forms-A -kartoitusta lisättiin (15 D-luokan 4-muotoista + 11 R-luokan 2-muotoista). Erityisesti urdun vakio 'h' HEH DOACHASHMEE (U+06BE → FBAA-FBAD) ja urdun sananloppuinen yeh YEH BARREE (U+06D2 → FBAE-FBAF) on nyt kartoitettu oikein Forms-A-paikkoihin, joita käytettiin väärin version v2.119.52 ALEF WASLA / NOON GHUNNA väliaikaisessa korjauksessa. Staattinen Forms-A-kattavuus kattaa nyt yli 40 lähdemerkkiä

YEH-HAMZA + vokaaliligatuurin jälkiajo (v2.119.58): proseduuriin _ApplyArabicShaping asemamuotoilun jälkeen lisätty jälkiajo kattaa 8 ligatuuriparia Forms-A-lohkossa U+FBEA-U+FBFB – YEH-HAMZA + ALEF / AE / WAW / U / OE / YU / E / ALEF MAKSURA. Kukin pari tuottaa itsenäisen muodon (FBEA / FBEC / FBEE / FBF0 / FBF2 / FBF4 / FBF6 / FBF9) sekä kanta+1-loppumuodon. Aloitus-/keskimuotojen paikat FBF8 / FBFB jätetään GSUB-moottorin käsiteltäväksi valinnan sfArabicGSUB kautta. Rakennettu saman rungon päälle kuin version v2.119.32 LAM-ALEF

Allah-ligatuuri (v2.119.60): nelimerkkinen sarja ALEF + LAM + LAM + HEH yhdistyy muotoon U+FDF2 ARABIC LIGATURE ALLAH ISOLATED FORM. Toteutettu koodipistetasoisena staattisena jälkiajona (post-pass) version v2.119.32 LAM-ALEF:n ja version v2.119.58 YEH-HAMZA:n jälkeen _ApplyArabicShaping-ketjussa

Bismillah-lauseen ligatuuri (v2.119.62): vakioinen 22 koodipisteen Bismillah-lause "بسم الله الرحمن الرحيم" yhdistyy yhdeksi glyfiksi U+FDFD ARABIC LIGATURE BISMILLAH AR-RAHMAN AR-RAHEEM. Ajetaan aivan ensimmäisenä esiajonakäsittelynä _ApplyArabicShaping-vaiheessa (ennen LAM-ALEF-vaihetta), joten yhdistetty Bismillah-glyfi saavuttaa muun putken yhtenä koodipisteenä eikä sitä muokata myöhemmissä korvauksissa

Public Query Helpers

GetArabicJoiningClass palauttaa Unicode-liitosluokan, jota staattinen arabian muotoilija käyttää. GetArabicPosition selvittää merkin sijainnin sarjassa erilliseksi, alku-, keski- tai loppuasemaksi, jotta kutsujat voivat tarkastaa tai peilata samoja muotoilupäätöksiä ennen tekstin tulostamista

How callers invoke it

Muotoiluputki ajetaan automaattisesti Unicode-tekstintulostusmetodien sisällä - erillistä "shape this" -kutsua ei vaadita. Välitä Unicode-syötteen arabian-, persian- tai urdunkieliset merkkijonot metodille THPDFPage.UnicodeTextOut tai THPDFPage.RtLTextOut, jolloin HotPDF kartoittaa jokaisen syötekoodipisteen sen esitysmuotoon ennen PDF-tekstinnäyttöoperaattorin kirjoittamista. Alkuperäiset Unicode-tavut kerätään myös kohteeseen FUnicodeUsedCps ToUnicode CMap -luontia varten, joten lukijan kopiointi/liittäminen ja ruudunlukijat näkevät edelleen alkuperäisen Unicode-hyötykuorman

Font requirements

Metodin RegisterUnicodeTTF kautta rekisteröidyn fontin on sisällettävä glyyfit sekä arabian Presentation Forms-B -lohkolle (U+FE70 - U+FEFC) että (persialle / urdulle) asianmukaiselle arabian Presentation Forms-A -alueelle (U+FB50 - U+FDFF). Suositellut fontit, jotka sisältävät koko joukon:

Noto Sans Arabic (latinalainen + arabialainen; Forms-A + Forms-B + Arabic Extended-A)

Noto Naskh Arabic, Noto Naskh Arabic UI.

Amiri (perinteinen Naskh, kattava Forms-A + Forms-B -kattavuus)

Scheherazade New (SIL, suunniteltu muslimimaailman kielille)

Microsoft Arabic Typesetting / Tahoma / Times New Roman (Windowsin mukana toimitetut, kattava Forms-B; joillakin on myös Forms-A-kattavuus)

Kun rekisteröidystä fontista puuttuu glyyfi johdetulle esitysmuodolle, HotPDF turvautuu Unicoden peruskoodipisteeseen ja lähettää sen muuttumattomana; kuluttajalukijat voivat tämän jälkeen yrittää omaa muotoiluaan (Acrobat, Foxit) tai hahmontaa merkin .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)

versio v2.119.59 toi valinnaisen ShapingFeatures: THPDFShapingFeatures-ominaisuuden ja THPDFShapingFeature-luettelon, joka nostaa muotoiluputken staattisen jälkikäsittelytaiton yläpuolelle automaattiseksi GSUB-ohjatuksi fonttikohtaiseksi korvaukseksi. Aseta PDF.ShapingFeatures := [sfArabicGSUB] soveltaaksesi rekisteröidyn fontin natiiveja arabiankielisiä hakuja init, medi, fina, isol, rlig, calt ja rclt ja lähettääksesi tuloksena olevat kontekstuaaliset glyyfi-ID:t; lisää sfCursiveAttachment soveltaaksesi GPOS-kaunokirjoituksen aloitus-/poistumisankkureita kyseiseen muotoiltuun jaksoon; lisää sfStandardLigatures latinalaisille standardiligatuureille (FB00-FB06 ff / fi / fl / ffi / ffl / ſt / st version v2.119.65 ApplyLatinLigatureRefinement kautta); lisää sfIndicShaping salliaksesi Devanagari-esijärjestelyn (v2.119.67). Oletusarvoinen [] säilyttää tavutasolla identtisen tulosteen kutsujille, jotka ovat riippuvaisia staattisesta käsittelyputkesta

Kun sfArabicGSUB on asetettu, staattinen Unicode Presentation Forms -muotoilija ohitetaan fontin omien GSUB-sääntöjen hyväksi. HotPDF lähettää natiiveja kontekstuaalisia glyyfi-ID:itä synteettisten koodipisteiden kautta, kun kyseiset glyyfit eivät ole saavutettavissa fontin cmap-kartasta, pitää upotetun osajoukon suljettuna ja kirjoittaa ToUnicode-käänteiskartoitukset kopiointia ja liittämistä varten. Kutsujien, jotka haluavat staattisen muotoilijan jatkavan toimintaansa fontin GSUB-ilmoituksen ulkopuolisille koodipisteille, tulisi jättää asetus sfArabicGSUB pois käytöstä ja luottaa staattiseen jälkikäsittelyketjuun

ToUnicode CMap -ligatuurin käänteiskartoitus (v2.119.61, v2.119.62, v2.119.65)

Metodin RegisterUnicodeTTF luoma Adobe-Identity-UCS ToUnicode CMap sisältää bfchar-käänteiskartoitusmerkinnät jokaiselle ligatuurin koodipisteelle, jonka jälkikäsittelyketju voi tuottaa. Versio v2.119.61 lisäsi 27 merkintää (8 LAM-ALEF + 18 YEH-HAMZA-perheestä + 1 Allah); versio v2.119.62 lisäsi Bismillahin (U+FDFD); versio v2.119.65 lisäsi 7 latinalaisen standardiligatuurin merkintää (FB00-FB06). Käyttäjän lukulaitteen kopiointi ja liittäminen ratkaisee minkä tahansa ligatuurin glyyfin takaisin alkuperäiseksi koodipisteiden sarjaksi, joten hahmonnettu PDF säilyy esteettömänä

PUA synthetic codepoint emit (v2.119.68)

Metodit AssignSyntheticCodepointForGID(GID; out CP): Boolean + GetSyntheticCodepointForGID(GID): Word antavat tuottajakoodin tulostaa sellaisia GSUB-korvaavia GID-tunnuksia, joilla ei ole luonnollista Unicode-koodipistettä saavutettavissa fontin cmap-taulukon kautta. Varaaja jakaa koodipisteitä Private Use Area -alueelta (U+E000 - U+F8FF, 6400 paikkaa) ja peilaa kohdistuksen kohteeseen FUnicodeCpToGid (jotta /CIDToGIDMap selvittää synteettisen CP:n takaisin kohde-GID:ksi kuluttajan lukulaitteessa), kohteeseen FAcroFormUnicodeAdvances (jotta version v2.65 rivitys löytää oikean em-murtoluvun) ja GID-kohtaiseen käänteishakutaulukkoon (jotta toistuvat varaustarpeet ovat idempotentteja). Käytä tätä devanagari-tavuryhmien muodoille, tyylivaihtoehdoille ja CJK-ideografisille variaatiosarjoille, joita GSUB tuo mukanaan mutta cmap ei tavoita

Suhde OpenType GSUB -moottoriin

Yllä kuvattu staattinen jälkikäsittelymuotoilija (v2.85.0 + v2.119.32 / 58 / 60 / 62) on oletusarvoisesti riippumaton OpenType GSUB engine -moottorista. Kun sfArabicGSUB otetaan käyttöön muuttujan ShapingFeatures kautta, GSUB-moottorista tulee osa tuottajapuolen tulostuspolkua: HotPDF hakee tietoja cmap-kartasta luodakseen perus-GID-taulukon, soveltaa natiiveja arabiankielisiä asento- ja konteksti-GSUB-hakuja kyseiseen glyyfiruniin, määrittää synteettiset koodipisteet sellaisille korvaaville glyyfi-ID:ille, joilla ei ole Unicode-esitysmuotoa, ja kutsuu metodia MarkUnicodeGlyphUsed pitääkseen korvaavat glyyfit upotetun fontin osajoukon sisällä

Jos korvaavilla glyfeillä ei ole Unicode-koodipistettä, kutsujat yhdistävät ShapingFeatures-asetuksen version v2.119.68 synteettisten PUA-koodipisteiden varaajaan, jotta korvaava GID on edelleen saavutettavissa tavallisen heksaputken kautta. Staattinen jälkiajoketju säilyy oletusarvoisena varavaihtoehtona koodipisteille, joita fontin GSUB-ilmoitukset eivät kata

Laajuus ja rajoitukset

BiDi-algoritmi jää tämän sivun ulkopuolelle: kutsujien on edelleen itse järjestettävä sekoitetut LTR- ja RTL-tekstijaksot tai käytettävä erillistä BiDi-kirjastoa. GPOS-, intialaisten/tiibetin/mongolin, heprean, N'Ko-, Adlam-, Thai/Lao- ja jaavan tuki sijaitsee nyt erillisillä valinnaisilla muotoilulippu- ja API-sivuilla, joten tämä sivu keskittyy vain staattiseen ja GSUB-pohjaiseen arabian muotoiluun

Katso myös: OpenType GSUB Substitution Engine, Automatic Shaping Pipeline (Phase 8), Syriac / Mongolian / Devanagari Shaping, THotPDF.AssignSyntheticCodepointForGID, THPDFPage.RtLTextOut, THPDFPage.UnicodeTextOut, CFF / OpenType Font Subsetting