[debian-devel:12790] Re: sensible-xtermemu_0.04

[Tomohiro KUBOTA <kubota@xxxxxxxxxxxxxxxxxxxxx>]

久保田です。

From: Nozomi Ytow <nozomi@xxxxxxxxxxxxxxxxxx>
Subject: [debian-devel:12789] Re: sensible-xtermemu_0.04
Date: Fri, 11 Aug 2000 03:20:30 +0900

>> 上記の説明のような意味です。xterm 内部で、setlocale(LC_CTYPE, "") の
>> 結果に従って、UTF-8 で動作したり EUC-* や ISO-2022-* で動作したり
>> Big5 で動作したりするようになっているべきです。
> どうもよくわからんなぁ。
> 所詮 term (表示する道具) なのにそういう support が必要ってことですか?

そうです。現在だと、EUC-JP を使う人は xterm の代わりに
kterm または krxvt (Debian の場合) を使ってますよね。まず、
EUC-JP を使う場合は xterm の代わりに kterm (など) を使わなきゃならない
という知識は、不要であるべきなんです。それに、自動的にターミナル
エミュレータを起動するような機構を持つソフトウェア (たとえば、
ウィンドウマネージャーの初期設定には、xterm を起動するメニュー
項目やアイコンを持っているものがありますよね) について、
いちいち手動で xterm の代わりに kterm (など) を使うように
設定を変更しないといけないでしょう。それは本来不要なはずの面倒な
手間だと思うのです (Debian の場合、alternative と x-terminal-emulator
のおかげで設定は1ヶ所だけで済みますが、それも不要であるべきだと
思っています)。

たった1ヶ所の設定だけじゃないかと思われるかも知れません。しかし、
それが積もると、山になるのです。これから Linux を始めようとする
入門者にとって、これは大きな負担です。熟練者にとっても、面倒です。
日本語環境の構築だけで1冊の本が書けてしまったりもするわけです。
私が language-env パッケージ (言語関係のドットファイルを半自動
作成する; もと user-ja パッケージ) を作ったのも、この状況を
なんとかしたいと思ったからです。

ターミナルエミュレータは、その上でさまざまなソフトウェアが動く
ための基盤となる重要なソフトウェアだと思っています。ターミナル
エミュレータの機能が不足していると、その上で動くすべての
ソフトウェアが影響を受けます。「所詮」という考え方はしていません。

...というような考え方には合意していただけないでしょうか？


>> すみません、「グリフ」というのが何か分かりません。
>別に謝る必要はないと思うけれど。
> JIS X 0208 のセンスで言えば、高低の「コウ」という文字に対して
> いわゆる「くち高」も「はしご高」も同じ「コウ」という文字の
> 異なる glyph (字形) といえばいいかな。これで通じますか?

だとすると、私は今まで、グリフの概念は忘れて議論していましたので
(「くち高」と「はしご高」の区別を問題にする人がいるということを
無視して、というか忘れて議論していましたので)、
私が「文字コード」と「グリフ」を混同するような議論をした、
ということは、ありません。また、今のところ、私のほうからそのことを
話題にするつもりはありません。

> 素人かどうかというのは関係ないと思いますが、それはさておき、
> 文字表示プログラムである term に多くを期待しすぎていると思います。
> まあ、文字から glyph への変換というのは term の仕事
> なのかもしれないけれど、文字と glyph の分離したモデルでも
> それを term に背負わせるのが良いかどうか.....

「くち高」と「はしご高」を区別するかしないか、というような微妙な
問題を言っているのではありません。たしかに、そういう微妙な問題を
問題にするのなら、term に多くを期待しすぎていると言えないことも
ないでしょうが...

>> # といっても、xterm が EUC-* とかをサポートしてほしいので、
> これって、term 的には表示に使う font の glyph エンコーディングが
> EUC という意味ですよね? だったらフォント指定の問題なんじゃないでしょうか。
> (というのがガイジンモードなのだろうか)

「表示に使う font の glyph エンコーディングが EUC」の意味が
いまいちよく分かりませんが、私の言いたいのは、xterm が
EUC-* を (ユーザーから見て) 正しく表示できる、という意味です。
要するに、「日本語を使うには、xterm の代わりに kterm というのを
使わなければならない」という知識が不要になればいいんです。


>> ISO-2022-* とか EUC-* とかの文字コードがきちんと表示できるので
>> あれば、それが X の仕組みの中でどのように扱われようが、つまり、
>> 従来のフォントが用いられようが、Unicode フォントにマッピング
>> されようが、ユーザーとしてはどちらでもいいです。
> 耐えられないくらい遅くてもいいですか?

私は X の内部動作については知らないですが、マッピングさせると
遅くなるという意味でしょうか？それとも、マッピングしないで
従来のフォントを使った場合に遅くなるのでしょうか？
耐えられないくらい遅いのは、いやです。

で、私がユーザーとして xterm に対して望んでいることは、
耐えられないくらい遅くなってしまうのでしょうか？

私は、それほど難しいことを望んでいるとは思っていないのですが。
EUC-* 対応なら kterm や hanterm がすでに実現しているし、
LC_CTYPE ロケールによる文字コードの自動切替なら 
XFree86 4.0 xterm がすでに実装していますし。
2カラム文字 (漢字、かな、ハングル) や合成文字 (タイ文字など) に
ついても、XFree86 4.0 xterm に対するパッチ (ただし、もちろん、
UTF-8 モード時のみ有効) が存在しますし。

---
Tomohiro KUBOTA <kubota@debian.or.jp>
http://surfchem0.riken.go.jp/~kubota/