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

[debian-devel:13338] Re: xearth



> 理想は,全てのcharacterを一意に表現できるようなcharacter coding 
> schemeがあれば良いと思うのですが,いかがでしょうか.

encoding scheme でしょうか、それとも character set でしょうか。
encoding scheme だけなら Unicode/ISO-10646 で実現できている
気がしますが。

> Alphabetを使っている方々はどうやら梯子「高」などの違いを,alphabetにおける
> italic とboldの違いと同様だと取っているような節があると思います.

半分はい半分いいえ。
Italic と bold (glyph image の違い) ではなく
ローマンとひげ文字 (ドイツ文字)とスクリプト体、
つまり glyph の違いと見るべきでしょう。
異体字の問題は、typeface の問題ではない、というのには同意しますが、
くちだろうがはしごだろうが、どちらも高という文字だ、というのも
また事実だと思います。
尚、Unicode では glyph と glyph image は区別していません。


> CJKでの問題は,別にそういう見ための効果でなく,意味も大きく違って来る,
> ということにあるのではないでしょうか.

そうです。


> Unicodeはその点で,問題があり,言語の設定を外部に依存しているために
> 普通のplain text file では,多言語で構成された文章が解読しようがない,というような
> 状況になるのではないだろうか,と思っています.

異体字の問題は文字の同一性の問題であり、言語タグとは関係ありません。
その文字を使って表現されている言語内容とも無関係です。
たまたま、Unicode が借りた規格が国家規格であるために言語と関係がある様に
思えてしまいますが、本質的には Unicode の文字に関する同値基準が
複数の借用規格に依存しており、その借用規格が相互に矛盾するものがある
(文字をエンコードしようとしているものと glyph をエンコードしようと
 しているもの) ためおかしな事になってしまう、という事です。
その意味では Markus 君がしている様に、ISO-10646 なフォントの日本風
variant の識別に ja を使うのは誤りで、jp を使うべきです。
(そう言っても彼は理解しないので、同意できる他の方も説得よろしく)


> 例えば日本ではいままででも,他と互換性のないEUC-JPとやらをメインに使っているので,
> 一番大切なのは,他のコードセットから変換してきて,又別のコードセットに変換しなおしても
> 情報のロスがないようなコードセットを採用する事なのでは無いでしょうか?

コードセットの話と文字集合の話が混同されていると思います。
必要なのは文字コード間の変換 (e.g. EUC-JP <-> SJIS) でしょうか、
それとも文字集合の変換 (e.g. JIS X 0208 <-> Big5) でしょうか。
「情報のロスがない」というのは Unicode の保証する round tripness で
実現できるているともいえます、なぜなら、ある文字集合に含まれている文字
が全て別の文字集合にも含まれているとは限らないから (e.g. JIS X 0208 ->
ASCII) です。

私は、文字集合間のマッピングは実際問題として必要になると思っています。
たとえば、UTF-8 な xterm から EUC-JP な kterm に copy & paste した時、
はしご高橋さんをくち高橋さんにマッピングするという事をユーザが選べる
(もちろんゲタ橋さんへのマッピングも選べる) 様にすべきだと思います。
Unicode な人達の中には、「はしご高」と「くち高」は別の文字だから
EUC-JP で表現できなくて当然だ、と考える人もいる様ですが、
そうなると JIS X 0208 な高 (包摂高) は Unicode には map されない
事になります (Unicode の「くち高」のコードポイントがエンコードしている
のは「包摂高」集合から「はしご高」集合を除いた「くち高」集合に
なってしまうから)。


> # と,思っているのですが,最近はLinuxはそういう実験的なOSで無くなっ
> # て来ている気もします.

Linux でやるよりは X でやる方が良いと思います。
Pango でも良いでしょう。