アラビア語 / ペルシア語 / ウルドゥー語シェーピングサポート

プロデューサー側のシェーピングパイプライン (v2.85.0 - v2.119.68)

HotPDFは、PDFテキスト出力中にUnicode入力のアラビア語、ペルシア語、ウルドゥー語のランをアラビア表示形に折りたたむプロデューサー側のシェーピングパイプラインを実行するため、コンシューマーリーダーは、独自のHarfbuzzクラスのシェーパーを必要とせずに、すぐにレンダリングできる位置/合字グリフを受け取ります。

パイプラインの機能

位置のシェーピング (v2.85.0): すべてのアラビア語の基本文字には、独立形 (isol)、語頭形 (init)、語中形 (medi)、語尾形 (fina) の最大4つの位置の形式があります。HotPDFは、各アラビア文字の結合クラスと、隣接する文字の結合クラスを検査し、出力前に、入力コードポイントを適切なアラビア表示形B（U+FE70 - U+FEFC）グリフにマッピングします。非結合文字、結合子、透過的な文字（結合マーク）、およびTatweelカシーダはすべて、Unicodeアラビア文字シェーピングアルゴリズムに従って処理されます。

LAM-ALEF の必須合字 (v2.119.32): アラビア語のUnicodeシェーピング仕様では、LAM (U+0644) の直後に ALEF (U+0627 プレーン、U+0622 上部にマッダ、U+0623 上部にハムザ、U+0625 下部にハムザ) が続く場合、単一の合字グリフ (U+FEFB - U+FEFC 独立/語尾形、適切なハムザ/マッダのバリアント付き) に折りたたむことが義務付けられています。これは、アラビア語タイポグラフィにおけるごくわずかな必須の合字の1つであり、正確さのために必要です。これらを別々のグリフとしてレンダリングすると、ネイティブの読者がすぐに不正な形式であると認識するテキストが生成されます。HotPDFは出力中に折りたたみを行うため、呼び出し元は独自のコードパスにHarfbuzzクラスのシェーパーを必要としません。

ペルシア語 / ウルドゥー語のコア9文字 (v2.119.35): ペルシア語とウルドゥー語は、アラビア表示形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) を含む）は、アラビア表示形A（U+FB50 - U+FDFF）に表示形を持っています。HotPDFは、位置のシェーピング中にこれらの文字を適切なForms-Aグリフにマッピングするようになったため、ペルシア語とウルドゥー語のテキストは、どのコンシューマーリーダーでも正しい語頭/語中/語尾/独立形でレンダリングされます。

アラビア文字拡張A + 補足 (v2.119.52, v2.119.56): 結合クラステーブルは、残りのアラビア文字拡張A文字 (ALEF WASLA / NOON GHUNNA / HEH バリアント)、アラビア文字補足 U+0750-U+077F、および上位のアラビア文字拡張A U+08A0-U+08FF の範囲をカバーするようになりました。静的な表示形Aのエンコーディングを持つ文字は、既存の4位置シェーパーを通じてマッピングされます。持たない文字（拡張Aのほとんど）は結合クラスの分類のみを取得するため、文字自体が変更されずに通過した場合でも、隣接する文字は正しくシェーピングされます。v2.119.56 では、v2.119.52 によって導入された2つの誤った Forms-A マッピング (U+06C2 / U+06C3) が修正されました。

ペルシア語 / ウルドゥー語 Form-B のフルカバレッジ (v2.119.57): 結合クラステーブルが拡張され、U+0672-U+06D5 の範囲全体（REH / DAL / SEEN / SAD / TAH / AIN / FEH / QAF / KAF / GAF / LAM / NOON / HEH / WAW / YEH のバリアントをカバーする約80文字）にまたがるようになり、26の新しい表示形Aマッピングが追加されました（15のDクラス4形式 + 11のRクラス2形式）。特に、ウルドゥー語の標準の 'h' HEH DOACHASHMEE (U+06BE → FBAA-FBAD) とウルドゥー語の語尾の yeh YEH BARREE (U+06D2 → FBAE-FBAF) は、v2.119.52 ALEF WASLA / NOON GHUNNA の一時的な修正によって誤用されていた Forms-A スロットに正しくマッピングされるようになりました。静的な Forms-A カバレッジは現在40以上のソース文字に及びます。

YEH-HAMZA + 母音合字のポストパス (v2.119.58): 位置のシェーピング後に _ApplyArabicShaping に追加されたポストパスは、Forms-A ブロック U+FBEA-U+FBFB の 8 つの合字ペア (YEH-HAMZA + ALEF / AE / WAW / U / OE / YU / E / ALEF MAKSURA) をカバーします。各ペアは、独立形 (FBEA / FBEC / FBEE / FBF0 / FBF2 / FBF4 / FBF6 / FBF9) と base+1 語尾形を出力します。語頭/語中形のスロット FBF8 / FBFB は、sfArabicGSUB のオプトインを介して GSUB エンジンに任されます。v2.119.32 LAM-ALEF と同じ骨格上に構築されています。

Allah 合字 (v2.119.60): 4文字のシーケンス ALEF + LAM + LAM + HEH は、U+FDF2 ARABIC LIGATURE ALLAH ISOLATED FORM に折りたたまれます。_ApplyArabicShaping チェーンの v2.119.32 LAM-ALEF と v2.119.58 YEH-HAMZA の後に、コードポイントレベルの静的ポストパスとして実装されています。

Bismillah フレーズの合字 (v2.119.62): 標準の22コードポイントのBismillahフレーズ "بسم الله الرحمن الرحيم" は、単一のグリフ U+FDFD ARABIC LIGATURE BISMILLAH AR-RAHMAN AR-RAHEEM に折りたたまれます。_ApplyArabicShaping (LAM-ALEF の前) の最初のプレパスとして実行されるため、折りたたまれた Bismillah グリフは1つのコードポイントとしてパイプラインの残りの部分に到達し、下流の置換によって変更されることはありません。

パブリッククエリヘルパー

GetArabicJoiningClass は、静的アラビア語シェーパーで使用されるUnicode結合クラスを返します。GetArabicPosition は、テキストを出力する前に呼び出し元が同じシェーピング決定を検査またはミラーリングできるように、ラン内の1つの文字を独立形、語頭形、語中形、または語尾形に解決します。

呼び出し元からの呼び出し方法

shaping pipeline は Unicode text emission methods 内で自動実行されます。明示的な「shape this」呼び出しは不要です。Unicode-input の Arabic / Persian / Urdu strings を THPDFPage.UnicodeTextOut または THPDFPage.RtLTextOut に渡すと、HotPDF は PDF text-showing operator を書き込む前に各 input codepoint を presentation form に map します。元の Unicode bytes も FUnicodeUsedCps に capture されて ToUnicode CMap generation に使われるため、reader-side copy / paste と screen readers は元の Unicode payload を引き続き参照できます

フォントの要件

RegisterUnicodeTTF を介して登録されたフォントには、アラビア表示形Bブロック（U+FE70 - U+FEFC）と（ペルシア語/ウルドゥー語の場合は）関連するアラビア表示形Aの範囲（U+FB50 - U+FDFF）の両方のグリフが含まれている必要があります。フルセットが同梱されている推奨フォント：

Noto Sans Arabic (ラテン文字 + アラビア文字; Forms-A + Forms-B + アラビア文字拡張A)。

Noto Naskh Arabic, Noto Naskh Arabic UI。

Amiri (伝統的な Naskh, Forms-A + Forms-B のフルカバレッジ)。

Scheherazade New (SIL, イスラム世界の言語向けに設計)。

Microsoft Arabic タイプetting / 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" (hello)

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 ルックアップが適用され、結果のコンテキストグリフ ID が出力されます。sfCursiveAttachment を追加すると、シェーピングされたランに GPOS の筆記体エントリ/終了アンカーが適用されます。sfStandardLigatures を追加すると、ラテン標準合字 (v2.119.65 ApplyLatinLigatureRefinement を介した FB00-FB06 ff / fi / fl / ffi / ffl / ſt / st) が適用されます。sfIndicShaping を追加すると、デーヴァナーガリー文字のプレパス並べ替え (v2.119.67) が有効になります。デフォルトの [] は、静的パイプラインに依存する呼び出し元に対してバイト単位で同一の出力を保持します。

sfArabicGSUB が設定されている場合、静的 Unicode 表示形シェーパーはバイパスされ、フォント固有の GSUB ルールが使用されます。HotPDF は、これらのグリフがフォントの cmap から到達できない場合、合成コードポイントを介してネイティブのコンテキストグリフ ID を出力し、埋め込まれたサブセットを閉じたままにして、コピーアンドペーストのために ToUnicode のリバースマッピングを書き込みます。フォントの GSUB が宣言している範囲外のコードポイントのカバレッジに対して静的シェーパーを引き続き実行したい呼び出し元は、sfArabicGSUB をオフのままにして、静的ポストパスチェーンに依存する必要があります。

ToUnicode CMap 合字リバースマッピング (v2.119.61, v2.119.62, v2.119.65)

RegisterUnicodeTTF によって出力される Adobe-Identity-UCS ToUnicode CMap には、ポストパスチェーンが生成できるすべての合字コードポイントの bfchar リバースマッピングエントリが同梱されています。v2.119.61 では 27 のエントリ (8 LAM-ALEF + 18 YEH-HAMZA ファミリー + 1 Allah) が追加されました。v2.119.62 では Bismillah (U+FDFD) が追加されました。v2.119.65 では 7 つのラテン標準合字エントリ (FB00-FB06) が追加されました。コンシューマーリーダーのコピー / ペーストは、合字グリフをソースのコードポイントシーケンスに解決して戻すため、レンダリングされた PDF はアクセシビリティに配慮した状態を保ちます。

PUA 合成コードポイント出力 (v2.119.68)

AssignSyntheticCodepointForGID(GID; out CP): Boolean + GetSyntheticCodepointForGID(GID): Word を使用すると、プロデューサーのコードは、フォントの cmap を介して到達できる自然な Unicode コードポイントを持たない GSUB 置換 GID を出力できます。アロケータは、私用領域 (U+E000 - U+F8FF、6400 スロット) のコードポイントを配布し、その割り当てを FUnicodeCpToGid (コンシューマーリーダーで /CIDToGIDMap が合成 CP をターゲットの GID に解決して戻すため)、FAcroFormUnicodeAdvances (v2.65 のワードラップが正しい em の割合を見つけるため)、および GID ごとの逆引き参照テーブル (繰り返しの割り当て要求がべき等になるため) にミラーリングします。これを、GSUB が導入するが cmap が到達しないデーヴァナーガリー文字のクラスター形状、文体による代替、および CJK の漢字の異体字シーケンスに使用します。

Open型 GSUB エンジンとの関係

上記の static post-pass shaper (v2.85.0 + v2.119.32 / 58 / 60 / 62) は default では OpenType GSUB engine から独立しています。ShapingFeatures で sfArabicGSUB が enabled の場合、GSUB engine は producer-side emission path の一部になります。HotPDF は cmap を参照して base GID array を構築し、その glyph run に native Arabic positional / contextual GSUB lookups を適用し、Unicode Presentation Form を持たない substitute glyph IDs 用に synthetic codepoints を割り当て、MarkUnicodeGlyphUsed を呼び出して substitute glyphs を embedded font subset 内に保持します

Unicode コードポイントを持たない置換グリフの場合、呼び出し元は ShapingFeatures を v2.119.68 の PUA 合成コードポイントアロケータと組み合わせることで、置換 GID が引き続き標準の 16 進パイプラインを介して到達可能になるようにします。静的なポストパスチェーンは、フォントの GSUB 宣言がカバーしていないコードポイントのデフォルトのフォールバックのままです。

範囲と制限事項

BiDi algorithm はこの page の範囲外です。callers は mixed LTR / RTL runs を自分で order するか、別の BiDi library を使用する必要があります。GPOS、Indic/Tibetan/Mongolian、Hebrew、N'Ko、Adlam、Thai/Lao、Javanese support は別の opt-in shaping flag と API pages に移ったため、この page は static および GSUB-based Arabic shaping のみに focus します