murawaki の雑記

はてなグループから移転してきました

U+0649 の表示

はじめてウイグル語を書いてみたわけだが、手元の環境では表示が正しくない。いろいろ調べたのでメモ。

問題は i。initial form や medial form が選択されるべきところで isolated form が表示される。

ウイグル語の i に対しては U+0649 ARABIC LETTER ALEF MAKSURA を使うことになっているらしい。どうもこの決定自体に問題があるようだが、アラビア語にもアラビア文字の歴史的経緯にも詳しくないので触れない。要するに元は特殊符号だったものをウイグル語では母音文字として使っていることになる。

U+0649 の presentation form は以下の通り。アラビア文字は presentation form にもコードポイントが割り当てられているから、その番号が使える。

U+FBE8 ARABIC LETTER UIGHUR KAZAKH KIRGHIZ ALEF MAKSURA INITIAL FORM
U+FBE9 ARABIC LETTER UIGHUR KAZAKH KIRGHIZ ALEF MAKSURA MEDIAL FORM
U+FEEF ARABIC LETTER ALEF MAKSURA ISOLATED FORM
U+FEF0 ARABIC LETTER ALEF MAKSURA FINAL FORM 

問題が上の二つで、名前が示すように、アラビア語ペルシャ語では使わない形。この二つは、Unicode の途中のバージョン (2.0?) で追加されたが、その時点では仕様がバグっていたらしい。joining class についても、3.0.0 で right-joining となっていた。つまり isolated form と final form しかもたないという扱い。それが 3.0.1 で dual-joining に修正された。Mozilla もそれに追従 (1, 2, 3)。

Unicode の仕様はそれでいいとして、実際に文字列を受け取ったときに誰がどうやって正しい表示を選ぶのか。これが全然わからない。問題が発生した環境は Windows XP だが、Windows Vista だと Mozilla でも IE でも正しく描画される。実は Windows では Geckouniscribe の関数を呼び出しまくり (bugzilla)。Linux は Pango。Mozilla のことだから自力で頑張っているのかと思っていた。もしかしたら uniscribe とフォントを自力で新しくしたら XP でもいけるのかもしれない。

Mozilla が自力で処理していると思って調べていて見つけたのが nsBidiUtils.cpp。マクロ PresentationFormB を見ると、元のコードポイントから Presentation Form B の番号の計算は、対応する Presentation Form B の開始位置に form の数値を足すことで実現している。これだと、U+FBE8 と U+FBE9 のように、基点の U+FEEF と全然違う場所にある form は見つけられない。

呼び出し元をたどると ArabicShaping <- Conv_06_FE_WithReverse <- nsFormSubmission::UnicodeToNewBytes <- nsFormSubmission::EncodeVal となっている。UnicodeToNewBytes にあるように、変更先の encoding が Windows-1256 の時のために Presentation Form を作っている。この恐ろしく限定された用途なら上記のマクロで問題ないのだろう。

OpenType の仕様を眺めた感じ、フォント側がいろんな情報を持っている様子。しかし Uniscribe がブラックボックスだからこれ以上調べるのは難しい。

Pango はどうなっているのかと調べてみる。2001年の時点で joining class の修正が入っているから、Arabic_Assign_Properties は正しいプロパティを与えるはず。実際 pango-view で ئۇيغۇر تىلى を表示すると i は正しい。しかし、デフォルトのフォントには ۇ が入っていない。

5月15日追記: アラビア系文字の基礎知識が計算機による処理も含めて説明しており良い。組版系の人が書いたもののようだ。