Підтримка формування арабської, перської та урду писемності

Конвеєр формування на стороні генератора (v2.85.0 - v2.119.68)

HotPDF запускає конвеєр формування на стороні генератора, який згортає вхідні символи Unicode для арабської, перської мов та урду в їхні презентаційні форми під час виведення тексту PDF, завдяки чому переглядачі отримують готові до рендерингу позиційні гліфи та гліфи лігатур без потреби у власному формувачі класу Harfbuzz

Що робить конвеєр

Позиційне формування (v2.85.0): кожна арабська базова літера має до чотирьох позиційних форм - ізольовану (isol), початкову (init), серединну (medi), кінцеву (fina). HotPDF перевіряє клас з'єднання кожного арабського символу та класи з'єднання його безпосередніх сусідів, а потім відображає вхідну кодову точку на відповідний гліф Arabic Presentation Forms-B (U+FE70 - U+FEFC) перед виведенням. Літери без з'єднання, з'єднувачі, прозорі символи (комбіновані знаки) та татвіл кашида обробляються відповідно до алгоритму Unicode Arabic Shaping

Обов'язкова лігатура LAM-ALEF (v2.119.32): специфікація арабського формування Unicode вимагає, щоб будь-кий LAM (U+0644), за яким безпосередньо слідує ALEF (U+0627 звичайний, U+0622 з маддою вгорі, U+0623 з хамзою вгорі, U+0625 з хамзою внизу), згортався в один гліф лігатури (U+FEFB - U+FEFC ізольовані / кінцеві форми з відповідними варіантами хамзи / мадди). Це одна з небагатьох обов'язкових лігатур в арабській типографіці, яка є необхідною для коректності; їх рендеринг як окремих гліфів створює текст, який носії мови відразу розпізнають як неправильний. HotPDF виконує згортання під час виведення, тому викликаючому коду не потрібен формувач класу Harfbuzz у власному коді

Основні 9 літер перської мови / урду (v2.119.35): перська мова та урду розширюють арабську літерами, яких немає в блоці Arabic Presentation Forms-B (U+FE70 - U+FEFC). 9 найбільш використовуваних таких літер - включаючи 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) та HEH GOAL (U+06C1) - мають презентаційні форми в блоці Arabic Presentation Forms-A (U+FB50 - U+FDFF). Тепер HotPDF відображає ці літери на відповідний гліф Forms-A під час позиційного формування, тому текст перською мовою та урду відображається з правильними формами init / medi / fina / isol у будь-якому переглядачі

Арабська Extended-A + Доповнення (v2.119.52, v2.119.56): таблиця класів з'єднання тепер охоплює решту символів арабської Extended-A (варіанти ALEF WASLA / NOON GHUNNA / HEH), арабське доповнення U+0750-U+077F та вищий діапазон арабської Extended-A U+08A0-U+08FF. Символи зі статичним кодуванням Presentation Forms-A відображаються за допомогою існуючого 4-позиційного формувача; символи без нього (більшість із Extended-A) отримують лише класифікацію класу з'єднання, щоб сусідні символи формувалися правильно, навіть коли сам символ передається без змін. У версії v2.119.56 виправлено два неправильні відображення Forms-A, представлені у v2.119.52 (U+06C2 / U+06C3)

Повне охоплення перської мови / урду Form-B (v2.119.57): таблиця класів з'єднання була розширена, щоб охопити весь діапазон U+0672-U+06D5 (близько 80 символів, що включають варіанти REH / DAL / SEEN / SAD / TAH / AIN / FEH / QAF / KAF / GAF / LAM / NOON / HEH / WAW / YEH), і додано 26 нових відображень Presentation Forms-A (15 для 4-форм класу D + 11 для 2-форм класу R). Зокрема, стандартна HEH DOACHASHMEE в урду (U+06BE → FBAA-FBAD) та кінцева YEH BARREE в урду (U+06D2 → FBAE-FBAF) тепер правильно відображаються на слоти Forms-A, які були неправильно використані тимчасовим виправленням ALEF WASLA / NOON GHUNNA у версії v2.119.52. Статичне охоплення Forms-A тепер охоплює понад 40 вихідних символів

Пост-прохід лігатур YEH-HAMZA + голосна (v2.119.58): пост-прохід, доданий до _ApplyArabicShaping після позиційного формування, охоплює 8 пар лігатур у блоці Forms-A U+FBEA-U+FBFB - YEH-HAMZA + ALEF / AE / WAW / U / OE / YU / E / ALEF MAKSURA. Кожна пара виводить ізольовану форму (FBEA / FBEC / FBEE / FBF0 / FBF2 / FBF4 / FBF6 / FBF9) плюс кінцеву форму base+1. Слоти початкової / серединної форм FBF8 / FBFB залишаються для рушія GSUB через прапорець sfArabicGSUB. Побудовано на тій самій основі, що й лігатура LAM-ALEF у версії v2.119.32

Лігатура Аллах (v2.119.60): чотирьохсимвольна послідовність ALEF + LAM + LAM + HEH згортається в U+FDF2 ARABIC LIGATURE ALLAH ISOLATED FORM. Реалізовано як статичний пост-прохід на рівні кодових точок після LAM-ALEF (v2.119.32) та YEH-HAMZA (v2.119.58) у ланцюжку _ApplyArabicShaping

Лігатура фрази Бісміллах (v2.119.62): стандартна 22-символьна фраза Бісміллах "بسم الله الرحمن الرحيم" згортається в один гліф U+FDFD ARABIC LIGATURE BISMILLAH AR-RAHMAN AR-RAHEEM. Запускається як найперший попередній прохід в _ApplyArabicShaping (перед LAM-ALEF), тому згорнутий гліф Бісміллах потрапляє до решти конвеєра як одна кодова точка і не змінюється наступними замінами

Публічні допоміжні методи запитів

Метод GetArabicJoiningClass повертає клас з'єднання Unicode, що використовується статичним арабським формувачем. GetArabicPosition визначає ізольовану, початкову, серединну чи кінцеву позицію одного символу в послідовності, щоб викликаючі програми могли перевірити або відтворити ті самі рішення щодо формування перед виведенням тексту

Як викликати

Конвеєр формування працює автоматично всередині методів виведення тексту Unicode - явний виклик "сформувати це" не потрібен. Передайте вхідні рядки арабською, перською мовами чи урду в кодуванні Unicode до THPDFPage.UnicodeTextOut або THPDFPage.RtLTextOut, і HotPDF відобразить кожну вхідну кодову точку на її презентаційну форму перед записом оператора виведення тексту PDF. Оригінальні байти Unicode також записуються у FUnicodeUsedCps для генерації ToUnicode CMap, тому копіювання / вставка з боку читача та екранні зчитувачі все одно бачать вихідні дані Unicode

Вимоги до шрифтів

Шрифт, зареєстрований через RegisterUnicodeTTF, повинен містити гліфи як для блоку Arabic Presentation Forms-B (U+FE70 - U+FEFC), так і (для перської мови / урду) для відповідного діапазону Arabic Presentation Forms-A (U+FB50 - U+FDFF). Рекомендовані шрифти, які поставляються з повним набором:

Noto Sans Arabic (латиниця + арабська; Forms-A + Forms-B + Arabic Extended-A)

Noto Naskh Arabic, Noto Naskh Arabic UI

Amiri (традиційний насх, повне охоплення Forms-A + Forms-B)

Scheherazade New (SIL, розроблений для мов мусульманського світу)

Microsoft Arabic Typesetting / Tahoma / Times New Roman (поставляються з Windows, повне охоплення Forms-B; деякі мають охоплення Forms-A)

Якщо у зареєстрованому шрифті відсутній гліф для похідної презентаційної форми, HotPDF повертається до базової кодової точки Unicode та виводить її без змін; тоді переглядачі можуть спробувати виконати власне формування (Acrobat, Foxit) або відобразити .notdef

Типовий процес роботи

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" (привіт)

PDF.EndDoc;

Автоматична інтеграція конвеєра фази 8 (v2.119.59 - v2.119.68)

У версії v2.119.59 представлено властивість ShapingFeatures: THPDFShapingFeatures та перелічення THPDFShapingFeature, що піднімає конвеєр формування вище статичного згортання після проходу до автоматичної заміни шрифтів на основі GSUB. Встановіть PDF.ShapingFeatures := [sfArabicGSUB], щоб застосувати нативні пошуки init, medi, fina, isol, rlig, calt та rclt арабської мови зареєстрованого шрифту та вивести отримані ідентифікатори контекстних гліфів; додайте sfCursiveAttachment, щоб застосувати анкери входу/виходу курсиву GPOS до цієї сформованої послідовності; додайте sfStandardLigatures для стандартних латинських лігатур (FB00-FB06 ff / fi / fl / ffi / ffl / ſt / st через ApplyLatinLigatureRefinement у v2.119.65); додайте sfIndicShaping, щоб увімкнути попереднє перевпорядкування Devanagari (v2.119.67). Значення за замовчуванням [] зберігає байт-ідентичний вивід для тих, хто залежить від статичного конвеєра

Коли встановлено sfArabicGSUB, статичний формувач Unicode Presentation Forms обходиться на користь власних правил GSUB шрифту. HotPDF виводить нативні контекстні ідентифікатори гліфів через синтетичні кодові точки, коли ці гліфи недоступні з cmap шрифту, зберігає вбудовану підмножину закритою та записує зворотні відображення ToUnicode для копіювання та вставки. Ті, хто хоче, щоб статичний формувач продовжував працювати для охоплення кодових точок поза тим, що оголошує GSUB шрифту, повинні залишити sfArabicGSUB вимкненим і покладатися на статичний ланцюжок пост-проходу

Зворотне відображення лігатур ToUnicode CMap (v2.119.61, v2.119.62, v2.119.65)

Adobe-Identity-UCS ToUnicode CMap, виведений методом RegisterUnicodeTTF, містить записи зворотного відображення bfchar для кожної кодової точки лігатури, яку може створити ланцюжок пост-проходу. У версії v2.119.61 додано 27 записів (8 для LAM-ALEF + 18 для сімейства YEH-HAMZA + 1 для Аллаха); у v2.119.62 додано Бісміллах (U+FDFD); у v2.119.65 додано 7 записів стандартних латинських лігатур (FB00-FB06). Копіювання / вставка у переглядачі повертає будь-який гліф лігатури до послідовності вихідних кодових точок, тому згенерований PDF залишається зручним для спеціальних можливостей

Виведення синтетичних кодових точок PUA (v2.119.68)

Методи AssignSyntheticCodepointForGID(GID; out CP): Boolean + GetSyntheticCodepointForGID(GID): Word дозволяють коду генератора виводити замінені GID GSUB, які не мають природної кодової точки Unicode, доступної через cmap шрифту. Розподільник видає кодові точки в Private Use Area (U+E000 - U+F8FF, 6400 слотів) і дублює призначення у FUnicodeCpToGid (тому /CIDToGIDMap перетворює синтетичну кодову точку назад у цільовий GID у переглядачі), FAcroFormUnicodeAdvances (тому перенесення слів v2.65 знаходить правильну частку em) та таблицю зворотного пошуку для кожного GID (тому повторні запити призначення є ідемпотентними). Використовуйте це для форм кластерів Devanagari, стилістичних альтернатив та послідовностей ідеографічних варіацій CJK, які вводить GSUB, але до яких cmap не доходить

Зв'язок із рушієм OpenType GSUB

Статичний формувач пост-проходу, опис якого наведено вище (v2.85.0 + v2.119.32 / 58 / 60 / 62), за замовчуванням є незалежним від рушія OpenType GSUB. Коли sfArabicGSUB увімкнено через ShapingFeatures, рушій GSUB стає частиною шляху виведення на стороні генератора: HotPDF звертається до cmap для побудови базового масиву GID, застосовує рідні арабські позиційні та контекстні пошуки GSUB до цієї послідовності гліфів, призначає синтетичні кодові точки для замінених ідентифікаторів гліфів, які не мають арабської презентаційної форми, і викликає MarkUnicodeGlyphUsed, щоб зберегти замінені гліфи всередині вбудованої підмножини шрифту

Для замінених гліфів без кодової точки Unicode розробники поєднують ShapingFeatures із розподільником синтетичних кодових точок PUA v2.119.68, тому замінений GID залишається доступним через стандартний шістнадцятковий конвеєр. Статичний ланцюжок пост-проходу залишається типовим варіантом для кодових точок, які не охоплені оголошеннями GSUB шрифту

Область застосування та обмеження

Алгоритм BiDi залишається поза межами цієї сторінки: розробникам все одно потрібно самим упорядковувати змішані послідовності LTR і RTL або використовувати окрему бібліотеку BiDi. Підтримка GPOS, Indic/Tibetan/Mongolian, Hebrew, N'Ko, Adlam, Thai/Lao та Javanese тепер знаходиться на окремих сторінках прапорців формування та API, тому ця сторінка зосереджена лише на статичному та базованому на GSUB арабському формуванні

Див. також: OpenType GSUB Substitution Engine, Automatic Shaping Pipeline (Phase 8), Syriac / Mongolian / Devanagari Shaping, THotPDF.AssignSyntheticCodepointForGID, THPDFPage.RtLTextOut, THPDFPage.UnicodeTextOut, CFF / OpenType Font Subsetting