アラビア文字タイポグラフィの表現体験とその技術的負債

2026年6月13日原文(lr0.org)

概要

アラビア語タイポグラフィ のウェブ実装における課題
欧文とアラビア文字 の組版文化の違い
カシーダ（kashida）による両端揃え の歴史的背景と技術的困難
Unicode・シェーピングエンジン の重要性
多言語対応の難しさ とその根本要因

アラビア語組版のフロントエンド課題

アラビア語混在のダッシュボード で、左端がギザギザになる問題の発生
デザインチームの要望 は「両端揃え（justified）」、しかし実装は不完全
欧文（Latin-script）では問題なし、アラビア語のみギャップ発生
CSSのtext-align: justify はアラビア語では期待通りに機能しない現状
Amiriフォント などの専用Webフォント導入が必要な状況
- 同時期に発生した他のバグ （PDF生成時の文字分離、誤ったUnicodeコードポイントによる検索不能など）も根本原因は同じ
- 表面上は小さなバグ だが、背後には深い技術的・歴史的課題が存在

アラビア語組版の歴史とカシーダ

アラビア語の伝統的組版 では、単語間スペースを伸ばさず、 文字内部の線分（カシーダ/kashida）を伸ばして両端揃え
Ibn Muqla による「al-khaṭṭ al-mansūb（比例書体）」の確立
- 文字ごとに形・長さの規則を定め、 どの文字ペアにカシーダを挿入できるか も詳細に規定
Ibn al-Bawwāb や Yāqūt al-Mustaʿṣimī など、後世の書家による体系化
Naskh、Nastaʿlīq、Dīwānī など、多様な書体とそれぞれの組版ルール
欧文組版では単語間スペースを伸ばす が、アラビア語では美観を損なうため不可
HTML上のモックアップ ではU+0640 TATWEELを手動挿入で再現

アラビア文字の構造的特徴と多言語拡張

アラビア文字は常に筆記体（cursive）、活字と手書きの区別なし
各文字は前後の文字との連結位置により4つの形 （独立形、語頭形、中間形、語末形）を持つ
一部の文字は前方非連結 で、単語内でも分断が発生
ペルシア語、ウルドゥー語、シンディ語など は独自の文字や形を追加
- 例：ペルシア語のپ（pe）、ウルドゥー語のھ（do-chashmī he）など
正しく表示するには各言語・書体ごとの対応が必須
- Noto Sans Arabicファミリーでは用途別にサブフォントを用意

Unicodeとシェーピングエンジンの役割

Unicodeは抽象的な1文字に1コードポイント を割り当てる
フォント側が位置ごとのグリフを持ち、シェーピングエンジンが描画時に適用
- OpenType機能（isol, init, medi, fina, rlig, mark, mkmk）で制御
アラビア語フォントは小さなプログラム のようなもの
シェーピングエンジン無しでは、単なる分断された文字列として表示
- 例：PDF生成エンジンが未対応の場合、バラバラに出力

まとめ：アラビア語組版の根本的課題

欧文組版の常識（スペースを伸ばす） はアラビア語には適用不可
アラビア語本来の両端揃え は、 文字形状の制御 と カシーダ挿入 が不可欠
現代Web技術（CSS、一般フォント）では未対応 な部分が多い
Unicodeとフォント設計、シェーピングエンジンの協調 が重要
多言語・多書体対応 には、技術的・歴史的な知識と配慮が不可欠

Hackerたちの意見

アラビア文字のテキストを正当化する学術的な扱いについては、こちらで見つけられます: https://quod.lib.umich.edu/j/jep/3336451.0023.104?view=text;...

└

すごく面白い記事だね！最後の方のOT/Unicodeの代替案やいろんな回避策がとても役に立ったよ :D （がんばれ、ブルー！）

アラビア語の切り離されたフォントがもっと一般的に使われるといいな、例えばこれみたいなやつ: https://www.arabaddigital.com/en/article/2100-Quarantining-o...

└

かつて試みられたことがあって、単語の中での位置に関係なく、各文字が一つの文字だけで済むような方法だったんだけど、残念ながら失敗した。 https://worksthatwork.com/6/unified-arabic

とても興味深いね。複雑なスクリプト（アラビア語、ナスタリック、インディックなど）に対応したテキストシェイパーとレンダラーをゼロから実装したところなんだ。これについて書くと、ストレッチがないのはOpenType仕様の欠陥だね。これを解決したいなら、シェイピングじゃなくてレンダリングの段階でやらなきゃいけない。シェイパーは利用可能なスペースについての情報を持ってないけど、レンダリングのときには個々のグリフを希望の幅にストレッチできるはず。ラテン文字の空白の幅を調整するのに似てるけど、もっと複雑だよ。実際にグリフをスケール変換で修正しなきゃいけないからね。アラビア文字の専門家ではないけど、これは可能だと思う。少なくとも面白い実験になるだろうし。もちろん、JSTFテーブルが正しい方法だけど、周りには混乱が多いみたい。もしかしたら、LLMの時代にもう一度挑戦できるかも。

└

KPのようなアルゴリズムが、極端なアルゴリズムの難しさなしにブレーク位置を最適化できるはずだと思う。ただ、入力がラテンブロック印刷よりもかなり複雑だからね。提案された行のコスト関数は、行の内容の単純な[0]計算可能な関数だし、動的プログラミングアルゴリズムを作って、各入力位置について、その位置でブレークする最適なレイアウトのコストを追跡できると思う。これで、立方体の時間がかかるアルゴリズムが得られるよ。（入力長nの場合、テーブルにnの値を埋める必要がある。各値は、その位置の前のテーブル全体をスキャンして、提案された行の長さに線形の複雑さで計算する。）実際の問題として、入力長nがあって、コードポイントで測定された信頼できる行長に上限Bがあるから、評価する信頼できる提案行はせいぜいnBになるし、テーブルの有効な見返りもB位置に制限されるから、時間の複雑さはO(nB^2)に減らせると思う。合理的な入力に対して結果が悪化しないなら、これはかなり許容できると思う。[0] アラビアレンダリングスタック全体を実装したら、簡単だよね。私はこの関数を計算する資格は全くないけど :)

└

でもレンダリングのとき、個々のグリフを希望の幅に伸ばすことができるよ。「個々のグリフ」:) アラビア語だから、単一のグリフを伸ばすことはないよ。形状を整えた後にやらないといけないから、次のラン（単一のアレフか結合された文字）を処理して、どれが伸ばせるかを知る必要があるんだ（それをレイアウトステップに投げる）。

これ、小さな誤字かな？ > 関連するルール、UAX #9のW2は、段落内の前の強い文字がアラビア文字であれば、数字をアラビア数字として再分類し、そうでなければヨーロッパ数字として分類します。どちらも内部の数字を左から右に表示するので、これは正しいです：地球上の数字は最も重要な桁から読むのが普通です。著者は「最も重要な桁が左にある」と言いたかったのかな？書かれている内容は、数字を読む順番や考える順番についての話で、著者は数字、特にハイフンで区切られた数字の集まりがページにどうレイアウトされるべきかを議論していると思う。

└

彼はテキストのストリームに関するレンダリングアルゴリズムについて話していると思う。基本的には、レンダリングの方向は読み方の慣習に従うべきだと言ってるんだ。一方で、正式なアラビア語では、数字が最も重要でない桁から最も重要な桁へ（右から左へ）塊で読まれるのは珍しくないよ。1984は「84と900と1000」と読まれる。著者がこれを知っているかはわからないけど。

└

これについて考えたことがあるんだ。アラビア語のテキストに埋め込まれたアラビア数字はリトルエンディアンなのかな？テキストは右から左に読むけど、数字は左から右のテキストと同じようにビッグエンディアン（大きい方から小さい方）で書かれてる。じゃあ、オリジナルのアラビア語の数字はリトルエンディアンなの？小さい方から大きい方に読む。面白いのは、数字は普遍的だってことだね。

この文章は素晴らしいね。興味深くて、魅力的で、詳細が満載で、アラビア語のレンダリングについてあまり考えたことがなかったのが信じられない。ここで思わず笑いそうになった部分があるよ：彼は「はい」と言う。結果は「簡略アラビア語」：初めが中間に、最後が孤立に、リガチャは削除される。これが世代を超えてアラビアのニュースルームを制覇する。8年後、Mrowaは無関係な派閥によってデスクで暗殺される、無関係な争いでね。それに、何億人もの人々がコンピュータで自分の言語をタイプセットできないなんて、悲しいよね。そして、我々の業界はその間に、あなたの食料品のためのAIネイティブAIを作ることに忙しかった（ちなみに、これがAIだって言った？）みたいなパフォーマンス的な無駄に。

└

もしかしたらAIがこれを解決してくれるかも？

Hacker Newsで議論の続きを見る

ハクソク