[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-devel:12793] Re: sensible-xtermemu_0.04
久保田です。
From: Nozomi Ytow <nozomi@xxxxxxxxxxxxxxxxxx>
Subject: [debian-devel:12792] Re: sensible-xtermemu_0.04
Date: Fri, 11 Aug 2000 13:47:47 +0900
> > EUC-JP を使う場合は xterm の代わりに kterm (など) を使わなきゃならない
> > という知識は、不要であるべきなんです。
>
> そぉかなぁ。不要であるべき、という理想論なら、
> EUC-JP を使う場合は、なんて前提もいらなくなるべきじゃないかなぁ。
> なんだか知らないけど表示させるとちゃんと表示される、
> そう「あるべき」なんじゃないんですか?
> EUC-JP なんかに時間をかけるより、Unicode + normalization を
> 推進して、かつフォントまわりも適切に扱う様にする方が
> いいんじゃないですか?
なるほど。それは一理あります。すべて Unicode で統一してしまえ、
そうすれば、文字コードについてユーザーが意識する必要はなくなる、
というわけですね。それには同意します。将来的には、たぶん、世の中は
そっちの方向に進むのでしょう。しかし、それは今すぐにはできないこと
です。
一方、私の言っていることは、それほど理想論ではないと思っています。
いまの枠組みのなかで、簡単に実現できることだと思っています。
そして、将来、Unicode が十分に普及し、従来の文字コードを扱う
必要がほぼなくなったところで、xterm の EUC サポートは役割を
終えることとなるでしょう。
ところで、normalization ってなんですか？
> > ターミナルエミュレータは、その上でさまざまなソフトウェアが動く
> > ための基盤となる重要なソフトウェアだと思っています。ターミナル
> > エミュレータの機能が不足していると、その上で動くすべての
> > ソフトウェアが影響を受けます。「所詮」という考え方はしていません。
> > ...というような考え方には合意していただけないでしょうか？
>
> 現実問題としてできませんね。ちょっと理想を追い始めると
> すぐに単純な世界でなくなると思います。
> 表示を単純な問題と割り切るなら、
> たとえば行末禁則とかはどうでもいいでしょう。
> しかしそのあたりをちゃんとしいときちんと読めない言語があります。
> たとえば、日本語がそうですが、「きゃ」なんてのを「き」と「ゃ」の
> 間で改行するのは表示として間違っているでしょう。これは、まあ一種の
> 合字の様なものですが、そういう language dependent な処理が必要に
> なった時点で term はもはや単純なものではありえないし、
なんだか、問題がすりかわっているような。私は、そんなことを
言いたいのではありません。行末禁則なんかどうでもいいと思っています。
あ、そうか、私が書いた「機能が不足」うんぬんという部分が誤解を
生じたみたいですね。私が言いたかった「機能」とは、行末禁則
のような機能ではなく、いま話題になっていること、つまり、
EUC などを表示できるという機能のことです。「その上で動く
すべてのソフトウェアが影響を受けます」というのは、たとえば、
あるソフトウェアを gettextize して日本語カタログを作ったとしても、
term にそれを表示する能力がなければ意味がない、というふうな
ことです。
> 逆に (いまの) xterm + UTF-8 のメリットというのはそういうのを
> 捨てて単純な処理に専心することにあると思います。
xterm + EUC だと行末禁則などを捨てて単純な処理に専心することが
できない (xterm + UTF-8 ならできるけど)、という意味ですか？
そんなことはないですよね。
> > 「くち高」と「はしご高」を区別するかしないか、というような微妙な
> > 問題を言っているのではありません。
>
> それが微妙な問題だというのは Unicode 信奉者的な発想ですね。
> 重要な問題ですよ。
どうせ EUC-JP でも区別できないですよね。だから、Unicode 信奉者
というのは間違っていると思います。
「重要」というのは相対的な問題です。私が「微妙」だと言ったのは、
xterm の議論をする上では些細な問題だと言いたかったのです。
Ytow さんの意見では、それは重要な問題だから xterm でも面倒を見る
べきだ、ということでしょうか？
Ytow さん自身の意見がよく分からないのです。xterm + UTF-8
では単純な処理に専心すべきだと言っておいて、一方では
「くち高」と「はしご高」の区別は重要だとおっしゃる。
私の意見では、
UTF-8 サポートすべき
EUC, ISO-2022, Big5, TIS620, etc サポートすべき
行末禁則処理 いらない
「くち高」「はしご高」の区別 いらない
となります。Ytow さんの意見では、どうなりますか？
> > いまいちよく分かりませんが、私の言いたいのは、xterm が
> > EUC-* を (ユーザーから見て) 正しく表示できる、という意味です。
>
> やっぱり文字コード (EUC-*) とグリフ (正しく表示できる) を
> 混同している。
きっと、私が言った「正しく」という言葉を、「はしご高」と
「くち高」の区別も含めて正しく、という意味にとったのですね。
そうではありません。そこまでの「正しさ」は求めていません。
かなや漢字を表示させたいときに ISO-8859-1 文字が表示されたり
するようなことがなければ、いまの文脈では十分に「正しく」表示
したことになります。xterm としては、それで十分だと思います。
それでも混同していることになりますか？
というか、xterm は文字を表示するのが第一の仕事なのだから、
ある文字コードが扱える、ということの中には、当然、その文字
コードが正しく表示できる、ということが含まれているはずだと
思うのですが。
> > 要するに、「日本語を使うには、xterm の代わりに kterm というのを
> > 使わなければならない」という知識が不要になればいいんです。
>
> いまゴソゴソやるより IIIMF の code が出て来るのを待って
> 動く方がいいと思いますけど。
IIIMF ってなんですか？
それから、
> すでに時遅しというべきかもしれないし、
というのと、矛盾してませんか？
> > 私は X の内部動作については知らないですが、マッピングさせると
> > 遅くなるという意味でしょうか？それとも、マッピングしないで
> > 従来のフォントを使った場合に遅くなるのでしょうか？
>
> 従来のスキームで Unicode なフォントを作って使うと
> たいそう遅くなるでしょう。
>
> > で、私がユーザーとして xterm に対して望んでいることは、
> > 耐えられないくらい遅くなってしまうのでしょうか？
>
> いまの xterm のままだとそうだと思います。
私が主張したこと(EUCなどのサポートと、LC_CTYPEを読みにいくこと)は、
Unicodeなフォントがなくても実現可能なので、耐えられないくらい
遅くなることなく実現できると思います。
---
Tomohiro KUBOTA <kubota@debian.or.jp>
http://surfchem0.riken.go.jp/~kubota/