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

[debian-devel:10313] Re: Draft 1 (Re: I18N Document)



岡@奈良先端です。

At Tue, 7 Sep 1999 22:03:47 +0900,
Tomohiro KUBOTA <kubota@xxxxxxxxxxxxxxxxxxxxx> wrote:
> 
> 久保田です。
> 
> 私は理想が低すぎるのでしょうか...
> もっときちんとした I18N (or M17N) を要求しろという意見が多いですね...
> すこしだけ、軌道修正することにします。

高い意識で私達の国の言葉を守ろう、ということです。

> > Windowsやglibcや次のバージョンのGTK+やQt-i18nの、内部コード
> > として使用されています(おそらく)。
> 
> えっ、glibc でも使われてるんですか?
> Windows 95/NT の内部で使われている (昔、Windows 95 を買ってまずやったのが、
> VFAT の解析でした。UNICODE で記録されるので、勢いで SHIFT-JIS と UNICODE の
> 対応表を作ってしまいました) のは知ってますが。

あとBeOSとかJavaとかは、表面的にもUNICODEでしたよね、確か。

内部コードとしては結構妥当かもしれません(が、中途半端なので
M17Nにはなりえない)。私達がどう思っていようとあっちの方々は
着実にUNICODEベースの実装を進めています。

 # 対応表は先に書いたftp.ora.comから入手できますし、
 # www.unicode.orgか何かから情報が得られると思います。

> あと、Tcl/Tk 8.1 の内部でも使用されていますが、内部で使用、というのは、
> それをまねた実装をしてみたい場合には参考になりますが、ユーザーにとっては
> 使ってないのと同然ですし。

まず、プログラマ相手のドキュメントなんですから、目を背けるの
は苦しいです。例えば、GTK+(1.4)ではテキストのレンダリングを
プラグイン化するので、プラグインプログラマはUNICODEについて
知らなければなりません。


> > > 通常は、EUC-JP のみをサポートすればいい。あるいは、EUC-JP のサブセット
> > > (ASCII and JIS X 0208) のみをサポートすればいい。この場合、
> > 
> > 本当にそうなのか、少し疑問です。
> 
> JIS X 0201 (半角カナ) → 使わないべきとされているので、あえて却下。
> JIS X 0212 (補助漢字) → 現在、L10N でもいいから使える実装ってありますか?
>   たとえば、X 用の DFSG Free なフォントがあるとか、kterm や Mule では
>   使えるとか...? 

UNICODEです。UNICODEフォントとか出てきてますし。

というか、EUC-JPにベッタリ依存すると絶対後で痛い目に遭いそう
です。コード非依存に記述できる抽象化を行うライブラリを通して
処理できる必要があり、wcstombs的な関数群はある程度これをサポー
トしていると言えますが、たぶん全然足りないと思います。

> > > 3.2. X Window System
> 
> > Xでは、XFontStructではなくXFontSetを基にテキストを表示しなけ
> > ればアルファベットと日本語を同時に表示できない。
> 
> 私は、XFontStruct も XFontSet も知らない (文脈からして、C の
> 関数ですよね?それっておいしい?とは言わないですが) ので、
> もっと一般的に、「英語以外では、ASCII 文字とそれ以外の文字が
> 共存するので、ASCII 用フォントとそれ以外の文字用のフォントが
> 同時に扱えるように、特にフォント選択機構を持つソフトウェアは
> 注意しなければならない」というふうなのでどうでしょうか。

Xの場合に限るとXFontStructとXFontSetに集約されるわけですが、
一般化して下さい。

> > 最近のGIMPの日本語化の話にもありましたが、GTK+でさえ依然完全
> > には国際化されていません。これはFontStructとFontSetの間のジ
> > レンマが発端です。GTK+のGtkFontSelectionダイアログではフォン
> > トを取得するように設計されているため、ASCIIと日本語の混在テ
> > キストを素直に表現できなくなっています。
> 
> フォントではなくて(コードセットごとの)フォントの集合を扱う
> 必要がある、ということでしょうか?

最終的にはそのようです。が、フォントセットを選択するようなダ
イアログは考えただけでも鬱陶しいので、選択するのはフォント、
ダイアログか何かがそこからフォントセットを推論するというのが
妥当なのかもしれません(それも最適かどうか疑問)。

Wordを見ていると、それとは違うアプローチです。選択するのはフォ
ントだが、文脈によってフォントが変わりまくる。日本語とASCII
で1セットという固まった概念ではなく、個々の部分が個々のフォ
ントを持っているみたいです、どうやら。

> ところで、なんと、Tcl/Tk 8.2 では、日本語と ASCII とが混在する
> 文字列を表示させておいて、そのフォントにたとえば helvetica とか
> 指定すると、日本語もゴシックになってくれたりします。times と
> 指定すると明朝体になりますし。(ちなみに、xtt 使ってます。)
> これはすごいですよ。

おそらく、そうあるべきでしょうね。

> Canna や Wnn だと、I18N どころか L10N でしかないと思うのです。
> X でいう XIM みたいな標準ができればいいのですが。あるいは、XIM
> って私は名前だけしか知らないのですが、X なしで XIM サーバーだけを
> インストールし、コンソールからそれを使うような仕組みって実現可能
> なんでしょうか?それか、コンソール上の多国語入力の標準をつくろう
> という動きはないでしょうか?

WnnはM17N化されてませんでしたっけ?

skkなんかは言ってみればL10Nですが、日本語の特徴を最大限に生
かした仕組みなので好まれているのだと思います。こういうのもア
リだと思う。
--
岡 充 (Mitsuru Oka)
奈良先端科学技術大学院大学