[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debian-devel:15709] Re: ja_JP.EUC-JP + ja_JP.UTF-8 サポート



GM> 	- X は問題ないか? (むつみさん?)
at> XLFDのfontset orderの問題があります.現在まともなISO-10646フォ
at> ントをもっていない上に,XLC_LOCALEではUTF-8 localeの場合
at> ISO-10646が優先されるように書かれているため,Xアプリやgtk1.2
at> アプリで問題が起きます.このfontset orderをlegacy fontset優
at> 先に書き換えることで,既存のフォントのままでも動きます.

これは実は Unicode BMP のグリフと文字の分離の不完全さのため

GM> 	- kernel や glibc のレベルではだいたい OK になってきているようだ
GM> 	- コンバータもだいぶサポートしている様子

というあたりもからんできます。BMP の包接基準のいいかげんさを考えると
X の selection なんぞも危ないかもしれません。で、

at> 見た目を考慮するとgtk1.2アプリについては
at> /etc/gtk/gtkrc.*.utf8みたいなファイルを作った方がいいかもし
at> れません.

といった解決は一つなのですが、グリフだけの問題にとどめず、
variants の正規化スキームも含めて工夫することで

at> 問題になりそうなところ
at> を上げると,日本語ファイル名の問題であったりとか,アプリケー
at> ションの都合で,デフォルトの保存するencodingがどうするとかそ
at> ういうところでしょうか.前者についてはlocaleがja_JP.eucJPと
at> かならG_BROKEN_FILENAMESという環境変数を使うことで回避できた
at> りしますが,移行後EUC-JPのファイル名をGNOMEアプリから読もう
at> とすると手段はちょっとありません.

あたりにも対処できるかもしれません。最悪 language tag を
使うという手もあるにはあるのですが、それくらいならば
variants のマルチレベル正規化をサポートする方が良いと思っています。
なぜ「思っています」なのかというと
ここ数年ほぼフルタイムの隠れ Java プログラマなのに
自分のコードさえ国際化する余裕がないからです。
(もうプログラマとしては歳だしね....)

どういう正規化を考えていたのか、5 年くらい前の話なのでよくは
思い出せないのですが、たとえば「くち高」「はしご高」でいうと、
Unicode BMP にはそれぞれ一つずつコードポイントがありますが、
元になった文字集合をたどると「くち高とはしご高が包接された
文字 (包接高)」「くち高」「はしご高」それぞれにコードポイントが
ないとどの「高」なのかわからなくなる事態が生じます。そこで、
これらの表現として、たとえば variant tag を使って

包接高 = BMP の「包接高 == くち高」のコードポイント
狭義の「くち高」 = BMP の「包接高」のコードポイント + オフセット 0
「はしご高」 = BMP の「包接高」のコードポイント + 
                 BMP の「はしご高」へのオフセット
BMP の「はしご高」コードポイントは正規表現としては使わない

などとすれば上記の事態は回避できます。
このやりかたを利用するかどうかというのはユーザ側で選択できる
必要があり、おそらくその選択はいくつかのパターンに集約できる
だろうから、そのややこしさの程度に応じてマルチレベルになる
だろう、というあたりまで考えて時間切れとなりました。
いまは Unicode version 3 に variant がきちんと列挙されて
いますから、当時よりはすこしはやりやすいだろうと思っています。
UCS4 もサポートするかどいうかので、オフセットの表現のしかたは
変わって来ると思います。できれば即値に近い形で済ませたいところ
ですが....

--
の