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

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



> EUC-JP を使う場合は xterm の代わりに kterm (など) を使わなきゃならない
> という知識は、不要であるべきなんです。

そぉかなぁ。不要であるべき、という理想論なら、
EUC-JP を使う場合は、なんて前提もいらなくなるべきじゃないかなぁ。
なんだか知らないけど表示させるとちゃんと表示される、
そう「あるべき」なんじゃないんですか?
EUC-JP なんかに時間をかけるより、Unicode + normalization を
推進して、かつフォントまわりも適切に扱う様にする方が
いいんじゃないですか?

> たった1ヶ所の設定だけじゃないかと思われるかも知れません。

いいえ、1 箇所だって不要であるべきだと思います。:)
(反語)

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

現実問題としてできませんね。ちょっと理想を追い始めると
すぐに単純な世界でなくなると思います。
表示を単純な問題と割り切るなら、
たとえば行末禁則とかはどうでもいいでしょう。
しかしそのあたりをちゃんとしいときちんと読めない言語があります。
たとえば、日本語がそうですが、「きゃ」なんてのを「き」と「ゃ」の
間で改行するのは表示として間違っているでしょう。これは、まあ一種の
合字の様なものですが、そういう language dependent な処理が必要に
なった時点で term はもはや単純なものではありえないし、
逆に (いまの) xterm + UTF-8 のメリットというのはそういうのを
捨てて単純な処理に専心することにあると思います。 


> 「くち高」と「はしご高」を区別するかしないか、というような微妙な
> 問題を言っているのではありません。

それが微妙な問題だというのは Unicode 信奉者的な発想ですね。
重要な問題ですよ。

> いまいちよく分かりませんが、私の言いたいのは、xterm が
> EUC-* を (ユーザーから見て) 正しく表示できる、という意味です。

やっぱり文字コード (EUC-*) とグリフ (正しく表示できる) を
混同している。

> 要するに、「日本語を使うには、xterm の代わりに kterm というのを
> 使わなければならない」という知識が不要になればいいんです。

いまゴソゴソやるより IIIMF の code が出て来るのを待って
動く方がいいと思いますけど。

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

従来のスキームで Unicode なフォントを作って使うと
たいそう遅くなるでしょう。 

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

いまの xterm のままだとそうだと思います。

> 私は、それほど難しいことを望んでいるとは思っていないのですが。

X のフォント周りのプロトコルが時代遅れなのでどうしようもない部分があります。

> 2カラム文字 (漢字、かな、ハングル) や合成文字 (タイ文字など) に
> ついても、XFree86 4.0 xterm に対するパッチ (ただし、もちろん、
> UTF-8 モード時のみ有効) が存在しますし。

リゲチャが出て来た時点で xterm を charcell font で使うメリット
というのが破綻していると思いませんか?