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

[Nozomi Ytow <nozomi@xxxxxxxxxxxxxxxxxx>]

devian-devel で引っ張るのがいいかどうかわからなくなって
きたけれど...

> ところで、normalization ってなんですか？

「が」と「か゛」を同一視するといった事が一例です。
他に、はしご高 = 高 + 異体コード というのも
私は含めて考えています。

> なんだか、問題がすりかわっているような。私は、そんなことを
> 言いたいのではありません。行末禁則なんかどうでもいいと思っています。

なぜ良いと思うか。それは、そういうのはたとえば roff や TeX が
処理する事であって term の仕事ではないと思っているからでしょう?
だったら、EUC かどうかというのも roff や TeX が処理すれば良いことで、
term は知らなくていいんじゃないでしょうか。term が気にすべきなのは
フォント切替えスキームではありませんか (もしそれが必要なら) ?

> EUC などを表示できるという機能のことです。

EUC を表示できる、というのがまだよくわかりませんが、
これは、グリフのエンコーディングの話ですよね?

>「その上で動く
> すべてのソフトウェアが影響を受けます」というのは、たとえば、
> あるソフトウェアを gettextize して日本語カタログを作ったとしても、
> term にそれを表示する能力がなければ意味がない、というふうな
> ことです。

「上で動く」のかどうかも疑問ですが、グリフエンコーディングを
term に合わせるというだけの話では?

> > 逆に (いまの) xterm + UTF-8 のメリットというのはそういうのを
> > 捨てて単純な処理に専心することにあると思います。 
> xterm + EUC だと行末禁則などを捨てて単純な処理に専心することが
> できない (xterm + UTF-8 ならできるけど)、という意味ですか？

EUC かどうかというのは term の処理すべき問題なのか? という事です。

> どうせ EUC-JP でも区別できないですよね。だから、Unicode 信奉者
> というのは間違っていると思います。

コードポイントの保存性と個々の文字概念の保存性の違いの話、
それを基礎とする文字コード変換の問題を source code separation
でマスクして無視している、という意味です。

> 「重要」というのは相対的な問題です。私が「微妙」だと言ったのは、
> xterm の議論をする上では些細な問題だと言いたかったのです。

EUC と UTF-8 の間の変換が可能かどうかで些細ではなくなるでしょう。

> Ytow さんの意見では、それは重要な問題だから xterm でも面倒を見る
> べきだ、ということでしょうか？

表示の問題で済まない問題を含んでいるかどうか、という事です。

> Ytow さん自身の意見がよく分からないのです。xterm + UTF-8
> では単純な処理に専心すべきだと言っておいて、一方では
> 「くち高」と「はしご高」の区別は重要だとおっしゃる。

それは UTF-8 にしたところで残る問題ですから。


>    UTF-8                             サポートすべき
>    EUC, ISO-2022, Big5, TIS620, etc  サポートすべき
>    行末禁則処理                      いらない
>    「くち高」「はしご高」の区別      いらない
> となります。Ytow さんの意見では、どうなりますか？

グリフのエンコーディングの話なのか
文字のエンコーディングの話なのか、
表示の際の文字とグリフの対応の話なのか
そこを分けて考えた方がよいのではないか、
という事です。

> > やっぱり文字コード (EUC-*) とグリフ (正しく表示できる) を
> > 混同している。
> きっと、私が言った「正しく」という言葉を、「はしご高」と
> 「くち高」の区別も含めて正しく、という意味にとったのですね。

違います。EUC-* というのは何をエンコードしていると
考えているのですか、という事です。

> かなや漢字を表示させたいときに ISO-8859-1 文字が表示されたり
> するようなことがなければ、いまの文脈では十分に「正しく」表示
> したことになります。xterm としては、それで十分だと思います。

だからそれはフォント切替えスキームの話でしょう?

> それでも混同していることになりますか？

していると思いますが。

> というか、xterm は文字を表示するのが第一の仕事なのだから、
> ある文字コードが扱える、ということの中には、当然、その文字
> コードが正しく表示できる、ということが含まれているはずだと
> 思うのですが。

文字コードとグリフは必ずしも対応しませんから、
「文字コードが正しく表示できる」というのは
一般には意味がありません。
term に文字コードのエンコードスキームを指定する事によって
適切にフォントを切替えて表示させるという話なのか、
それとも文字集合の切替えスキームを指定することによって
フォントを切替えて表示させるという話なのか、
どっちでしょう。


> IIIMF ってなんですか？

X でもコンソールでもなんでも使えると言われている
インプットメソッド。

> それから、
> > すでに時遅しというべきかもしれないし、
> というのと、矛盾してませんか？

なぜですか?

> 私が主張したこと(EUCなどのサポートと、LC_CTYPEを読みにいくこと)は、
> Unicodeなフォントがなくても実現可能なので、耐えられないくらい
> 遅くなることなく実現できると思います。

ISO2022 アレルギーな人にそのあたりを説得するのが大変なのですが....
「Unicodeなフォントがなくても実現可能」というのは
kterm/mule 文化な発想という気がします。
「そんなの面倒だからヤだ」というのに対する答えになり得るのが
xterm + UTF-8 のメリットだと思います。