[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 もサポートするかどいうかので、オフセットの表現のしかたは
変わって来ると思います。できれば即値に近い形で済ませたいところ
ですが....
--
の