アカウント名:
パスワード:
フォントだけでは決まりません。XFree86 XTerm の実装では、半角用フォントと全角用フォントのふたつを用意して、文字ごとにどちらかを使うというふうになっています。
文字幅が重要なのは、たとえば tcsh の漢字サポート版では、漢字を入力した後に BS キーや ← キーを押すと、2 文字分のカーソル移動コントロールコードが出力され、kterm や rxvt などの動作とマッチするようになっています。つまり、すべてのプログラムで統一した解釈になっている必要があります。
もし現在のその統一された動作が変だから変更しようというのなら、世界中のプログラムをそのように書き換える必要があります。しかも「移行期」を設けることはできません。一晩で完全に移行してしまう必要があります。ぼくにはそれを実現するだけの政治力はないですし、仮にあったとしても、人々を混乱に陥れるだけの大義名分がありません。
ただ、文字幅に関するデファクトスタンダードを持っているのも、それを変更する(とすれば)コストを払う羽目になるのも、東アジア人です。そのことについて無知な欧米人が、「文字幅に関するスタンダードを(従来はなかったので)新しく作るのだ」と称して勝手なことをされては困る(彼らは困らない。われわれだけが困る。しかも彼らはわれわれが困っていることに無知でいられる)ので、この点はきちっと押さえておく必要があると思うのです。コントロールコード 0x08 と倍幅文字の関係については、Markus Kuhn の説得に成功したので、まあ一安心です。
そして、これがほんとうにきちんと動作するためには、個々の文字について、どれが半角でどれが全角、ということが決まってないといけません。日本においても規格は存在しないですが、PC-8801 の時代から、JIS X 0208 文字を (NEC 独自規格の 2 バイト半角文字を除き) 半角で表示する実装は、ぼくは知りません。
kterm を使えばいいというのはその通りかもしれませんが、国や言語ごとに別のソフトウェアを使うのはもうやめよう、というのが国際化の流れなわけですし。実際、国や言語ごとに別々のソフトウェアをメンテできるほど、オープンソースの世界は人材豊富ではありません。
もし現在のその統一された動作が変だから変更しようというのなら、世界中のプログラムをそのように書き換える必要があります。
たしかに,readline や curses 等その他多数のプログラムを直すより,xterm ひとつ直す方が楽なのは事実ですが…. でも,その多くのプログラムは,結局「EUC-JP の G1 の 文字はみんな2カラムだ」みたいな前提を置いて動いているわけで,そういうプログラムは UTF-8 対応するときに そういう前提を捨てざるを得ないわけだから,今のうちにそれをやってしまって,「現在の xterm + luit でも 動くようにする」のはいかがなものでしょうか.それとも,なにがなんでもポンド記号「£」は全角でないといや? UTF-8 になっても?
移行期間はどうするか? もちろん kterm を使えばいいんですよ.UTF-8 なんか使いたくない? それこそ,kterm を使い続ければいいんですよ.
それとも,なにがなんでもポンド記号「£」は全角でないといや? UTF-8 になっても?
なんか意図が伝わらなさそうな書き方をしてしまったので補足します.
日本の既存のプログラムを修正しないで動作させようとすれば,既存のプログラムが想定していた前提条件を満足してやる必要があります.そのためには,たとえば,ポンド記号「£」は「全角」でなければなりません.しかし,それは日本の既存プログラムの都合であって,たとえば英国に行けば,日本でポンド記号が使われていたのとは比較にならない規模でポンド記号が使われているわけで,しかも,もちろんそれは「全角」ではありません.そこで,英国の既存のプログラムを修正しないで動作させようとすれば,逆にポンド記号「£」は「全角」であってはならないことになります.
でも,お互いそれは,既存のプログラムがそうなっているという勝手な都合に過ぎないわけで,どちらかを相手に押し付けて済ませるのが正しい解決ではないでしょう.(いや,どちらかと言えば,外国人である日本人が,英国人の文字であるポンド記号に対して強く主張しても受け入れられないでしょうけれど.もちろん,ポンド記号以外にも問題になる文字はあって,それぞれの文字によって関係者の顔ぶれが変わります.)
一方で,既存のプログラムを手を入れることなく使い続けたいという要求は確実にあるわけで,そのために,xterm に互換モードを設けて,既存プログラムを救済するということは可能でしょう.
既存プログラムの救済手段としてある文字が「全角」であるべきかどうかということと, UTF-8 対応の多言語端末プログラムとして xterm がある文字を「全角」で表示すべきかどうかということとは,別の問題として考えた方がいいと思うのですが, 前者の面ばかり強調されるようだったので, 上のように書いたのです. (もちろん,後者の環境で動作するプログラムは,必要に応じてそれなりに修正するわけです.日本のプログラムだけじゃなくて,世界中のプログラムをね.)
XTerm に互換モードを設けて、というのは、UTF-8 で使うのであれば、そういう方法がいいと思います。デフォルトはポンド記号は半角にすべきです。UTF-8 は世界のどこでも使われる予定であり、世界の大部分 (CJK を除く) ではポンド記号は半角だったのですから (CJK な人々は修正を迫られるか互換モードを使うことになります)。現状の XTerm では、デフォルトの動作はそうなっていますが、互換モードは存在しません。というか、デフォルトしかありません。
で、将来、XTerm で EUC-JP などが使えるようになったときにどうするかですが、ポンド記号を半角にして EUC-JP を使ってきた人はいません。EUC-JP でポンド記号を使うときは必ず (世界のどこでも) 全角だったので、ポンド記号が全角になるほうがデフォルトになるべきです。こちらの場合は UTF-8 の場合とは異なり、修正を迫られる人は世界のどこにも存在しません。
素朴な疑問。
UNIX統一仕様の一部である端末制御仕様の X/Open Curses では多カラム文字のための処理が定義されていて、 そこでは明らかに、locale DB によるカラム数情報を参照 することが意識されてるんだけど、そういった情報と 連動させるとかそういった話はないのかしらん?
特定の文字が端末において何カラムになるかというのは、 ロケール情報の一部であり、UNIX標準では wcwidth(3) で取得可能です。
まっとうな実装なら、端末も Locale 対応にして、 幅設定するには Locale DB を改変して
はい。wcwidth(3) は知ってます。実際、 Robert Brady さんパッチを改良したぼくのパッチでは、wcwidth(3) を使っています。
これの最初の「不具合」は、 「en_US.UTF-8 ロケールでは wcwidth(3) の定義がいいかげんなので 自前でデータベースを持ったほうがいい」というもので、 そんなの、ロケール定義を実装すればしまいだろ、とか 思ったものです。が、それは無視するとしても、 wcwidth(3) そのものが移植性に乏しいとか (BSD なみなさん、がんばってください)、 リモート環境ではうまくいかないとかの問題が指摘されています。 ですので、 wcwidth(3) が正しく動くことは必要なことではありますが、 だからといってロケール定義を好き勝手にしてもきちんと動くという わけではないです。 ぼくはそれでも、リモートでない場合とか、自分で分かっててやるぶんには かまわないだろうと思うのですが...
あと、この XTerm に固有の問題ですが、 wcwidth(3) は wchar_t を引数にとる一方、 XTerm は内部コードとして Unicode を採用しているために 変換が必要になる、という問題があります。 Unicode とワイド文字の間の変換を、 移植性よく、効率よく書くにはどうすればいいのでしょうか? いちおう、上記のぼくのパッチには、それらしきコードが書いてありますが。 XTerm + luit のアプローチだと、XTerm そのものは エンコーディング変換を一切やらない建前だし (そうすることで XTerm 本体の保守性を保つのだとか。ぼくがメンテするのではないので、 そう言われると反論しにくい)、かといって luit はロケールを使わずに ISO-2022 をそのまま解釈する構造になっていて、 やはりワイド文字とかマルチバイト文字とかとはなじみが悪いです。 というわけで、wcwidth(3) に基づいた文字幅を実現するのは このままではなかなか難しそうです。
ところで、合成文字や bidi の場合は、wcwidth(3) はどのように動作すべきと 定められているのでしょうか?
Single UNIX Specification では,wcwidth() は,ヌル文字 L'\0' の場合 0,非表示文字の場合 -1, その他の場合は文字幅を示す整数値を返すことになっています.BIDI や合成文字についての言及はありません.
もともと wcwidth() や,その導入の元になった column position (桁位置) という概念自体が,POSIX.2 の一部のユーティリティ (fold とか pr -w とか ls -C とか vi とか) にある「文字の桁幅」を意識した処理のためで,その定義も「ある行の中のある文字の桁位置は,その行の中で,その文字の前にある文字の桁幅の合計に 1 を加えたものと定義する」というくらいしか書いてなくて, 行の途中で文字の進行方向が変わったり, 他の文字と合成されて表示されるような文字があったりする場合は全く考慮されていません.
あと、この XTerm に固有の問題ですが、 wcwidth(3) は wchar_t を引数にとる一方、 XTerm は内部コードとして Unicode を採用しているために 変換が必要になる、という問題があります。 Unicode とワイド文字の間の変換を、 移植性よく、効率よく書くにはどうすればいいのでしょうか?
ワイド文字のエンコーディングには××を使わなければならない,といった標準はないので (__STDC_ISO_10646__ が定義されていれば別ですが), 完全な移植性を求めるなら, 「いったん mbtowc() でマルチバイト文字に変換してから Unicode に直す」 しかありません.で,それは決して「効率よく」はない.
昔々,EUC が AT&T UNIX Pacific で規定された (厳密に言えば日本語 UNIX 諮問委員会の案を一般化しただけですが) ときには,マルチバイト文字とワイド文字との間の関係は完全に明文化されていたけれど,それは ISO/IEC 2022 の枠組みを強烈に意識していたので,その枠に収まらない Shift_JIS や Big5 での実現を排除してしまうことになり,それが標準になることもなかった.(実際 UNIX Pacific も, wchar_t を16ビットから32ビットにしたときに,ワイド文字の内部形式の互換はとらなかった.)
たとえば,HP-UX では EUC-JP も Shift_JIS も 両方サポートしていたけれど,ワイド文字の形式は UNIX Pacific 方式とは違っていて,しかも, たとえ同じ文字でも エンコーディングが違えばワイド文字の表現まで 変わってしまうのでびっくりしたことがあります. Solaris では一応 EUC-JP と Shift_JIS とでは 同じ文字のワイド文字表現は同じにしていましたが, UTF-8 になるとワイド文字が UCS-4 になってしまった ので,そういう意味での互換性はなくなりました.
ワイド文字が Unicode であることを明文化している システム (Windows NT の UCS-2 と glibc 2.2 の UCS-4) もありますし,たとえばマルチバイト文字の エンコーディングが UTF-8 の場合,wchar_t が32ビットなら,その内部表現が UCS-4 になるのが一番自然でしょうが,その想定が必ず正しいという保証はありません.たとえば,UTF-16 の範囲の文字しか使わないと思えば,上のビットが何ビットか余っていることになるので,それを別の用途に使いたいと思う人がいるかもしれません. (もっとも, Markus は wchar_t が Unicode でない実装を否定したいようですがね.)
これってDevanagariやThaiの扱いはどうなるんでしょ?
どんな仕様を提案するにしても、今日本人が欧米人に対して言うように、 後で「無知な日本人めっ」とか言われることになったら悲しいよね。
端末エミュレーターに限って言えば, 一文字が一定幅か,その整数倍の幅をもつという前提が (近似的にでも) 成り立たない文字に 適用するのはかなり困難でしょう. Devanagari や Thai がどうかは知らないので, なんとも言いかねます.
インド人やタイ人だってコンピューターを 使っているわけですから,勝手な思い込みで決めつけず,謙虚に意見を聞けばいいのです. 何にも知らないくせに, 「これなら世界中の文字に対応できる」とか, 「どうせ××文字なんて使うやつは少ないから, 後回しでいいんだ」とか, 偉そうに主張するのが一番嫌われる.
日本人なんておとなしいものですよ. なんせ,「これでは日本語が通らない」としか言わないのだから.
タイは、TIS620 というエンコーディングが使われており、結合文字が必須です。おそらくタイ人自身による実装である xiterm+thai というのが Debian では利用可能です。XTerm も UTF-8 モードではかなり前から結合文字の使用が可能です。これはタイ人じゃなくて Robert Brady さんという人の仕事です。ちなみに XTerm で全角文字が使えるようになったのも、この人のおかげです。
すみませんが、インドのことについては知りません。
「これでは日本語が通らない」としか言わないかというと、そうでもなくて、ASCII と CJK に対応したものを作って「国際化ができた」とか言うことがよくあります。
これは一本取られましたね. 「良くも悪くも,日本語のことしか考えていない」 という方が近いかな.
遠い外国の事情はわからないことが多いので, 「とりあえず日本語は通ります」といって出すのが いいのかもしれません.他の国の人が試して, 問題があれば直してくれるかもしれませんから.
それでしたら、問題があるかどうか試してほしいという意思表示が必要だと思います。「とりあえず日本語は通ります」という言い方だと、「ああ、あれは日本語専用だからわれわれには関係ない」と思ってほっとかれるおそれがあります。
ぼくは、誇大広告になるのを覚悟で、「マルチバイト文字に対応するように改良した。CJK はマルチバイトが必要だし、将来 Unicode を使いたくなったら Unicode もマルチバイトだからこのパッチが役立つ。従来の 8 ビットエンコーディングには悪影響を与えないはずだからこのパッチを採用してくれ」とかいうふうに言うことにしています。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
文字の幅 (スコア:0)
ではないんですかね。従来の US-ASCII:JIS X 0208 =
1:2 が欲しいなら、そういうフォントを使えばいいの
では…
従来の文字幅が欲しいなら kterm を使えばいいわけだし、
どうでもいいじゃないですか。
Re:文字の幅 (スコア:1)
フォントだけでは決まりません。XFree86 XTerm の実装では、半角用フォントと全角用フォントのふたつを用意して、文字ごとにどちらかを使うというふうになっています。
文字幅が重要なのは、たとえば tcsh の漢字サポート版では、漢字を入力した後に BS キーや ← キーを押すと、2 文字分のカーソル移動コントロールコードが出力され、kterm や rxvt などの動作とマッチするようになっています。つまり、すべてのプログラムで統一した解釈になっている必要があります。
もし現在のその統一された動作が変だから変更しようというのなら、世界中のプログラムをそのように書き換える必要があります。しかも「移行期」を設けることはできません。一晩で完全に移行してしまう必要があります。ぼくにはそれを実現するだけの政治力はないですし、仮にあったとしても、人々を混乱に陥れるだけの大義名分がありません。
ただ、文字幅に関するデファクトスタンダードを持っているのも、それを変更する(とすれば)コストを払う羽目になるのも、東アジア人です。そのことについて無知な欧米人が、「文字幅に関するスタンダードを(従来はなかったので)新しく作るのだ」と称して勝手なことをされては困る(彼らは困らない。われわれだけが困る。しかも彼らはわれわれが困っていることに無知でいられる)ので、この点はきちっと押さえておく必要があると思うのです。コントロールコード 0x08 と倍幅文字の関係については、Markus Kuhn の説得に成功したので、まあ一安心です。
そして、これがほんとうにきちんと動作するためには、個々の文字について、どれが半角でどれが全角、ということが決まってないといけません。日本においても規格は存在しないですが、PC-8801 の時代から、JIS X 0208 文字を (NEC 独自規格の 2 バイト半角文字を除き) 半角で表示する実装は、ぼくは知りません。
kterm を使えばいいというのはその通りかもしれませんが、国や言語ごとに別のソフトウェアを使うのはもうやめよう、というのが国際化の流れなわけですし。実際、国や言語ごとに別々のソフトウェアをメンテできるほど、オープンソースの世界は人材豊富ではありません。
Re:文字の幅 (スコア:1)
たしかに,readline や curses 等その他多数のプログラムを直すより,xterm ひとつ直す方が楽なのは事実ですが…. でも,その多くのプログラムは,結局「EUC-JP の G1 の 文字はみんな2カラムだ」みたいな前提を置いて動いているわけで,そういうプログラムは UTF-8 対応するときに そういう前提を捨てざるを得ないわけだから,今のうちにそれをやってしまって,「現在の xterm + luit でも 動くようにする」のはいかがなものでしょうか.それとも,なにがなんでもポンド記号「£」は全角でないといや? UTF-8 になっても?
移行期間はどうするか? もちろん kterm を使えばいいんですよ.UTF-8 なんか使いたくない? それこそ,kterm を使い続ければいいんですよ.
Re:文字の幅 (スコア:1)
なんか意図が伝わらなさそうな書き方をしてしまったので補足します.
日本の既存のプログラムを修正しないで動作させようとすれば,既存のプログラムが想定していた前提条件を満足してやる必要があります.そのためには,たとえば,ポンド記号「£」は「全角」でなければなりません.しかし,それは日本の既存プログラムの都合であって,たとえば英国に行けば,日本でポンド記号が使われていたのとは比較にならない規模でポンド記号が使われているわけで,しかも,もちろんそれは「全角」ではありません.そこで,英国の既存のプログラムを修正しないで動作させようとすれば,逆にポンド記号「£」は「全角」であってはならないことになります.
でも,お互いそれは,既存のプログラムがそうなっているという勝手な都合に過ぎないわけで,どちらかを相手に押し付けて済ませるのが正しい解決ではないでしょう.(いや,どちらかと言えば,外国人である日本人が,英国人の文字であるポンド記号に対して強く主張しても受け入れられないでしょうけれど.もちろん,ポンド記号以外にも問題になる文字はあって,それぞれの文字によって関係者の顔ぶれが変わります.)
一方で,既存のプログラムを手を入れることなく使い続けたいという要求は確実にあるわけで,そのために,xterm に互換モードを設けて,既存プログラムを救済するということは可能でしょう.
既存プログラムの救済手段としてある文字が「全角」であるべきかどうかということと, UTF-8 対応の多言語端末プログラムとして xterm がある文字を「全角」で表示すべきかどうかということとは,別の問題として考えた方がいいと思うのですが, 前者の面ばかり強調されるようだったので, 上のように書いたのです. (もちろん,後者の環境で動作するプログラムは,必要に応じてそれなりに修正するわけです.日本のプログラムだけじゃなくて,世界中のプログラムをね.)
Re:文字の幅 (スコア:1)
XTerm に互換モードを設けて、というのは、UTF-8 で使うのであれば、そういう方法がいいと思います。デフォルトはポンド記号は半角にすべきです。UTF-8 は世界のどこでも使われる予定であり、世界の大部分 (CJK を除く) ではポンド記号は半角だったのですから (CJK な人々は修正を迫られるか互換モードを使うことになります)。現状の XTerm では、デフォルトの動作はそうなっていますが、互換モードは存在しません。というか、デフォルトしかありません。
で、将来、XTerm で EUC-JP などが使えるようになったときにどうするかですが、ポンド記号を半角にして EUC-JP を使ってきた人はいません。EUC-JP でポンド記号を使うときは必ず (世界のどこでも) 全角だったので、ポンド記号が全角になるほうがデフォルトになるべきです。こちらの場合は UTF-8 の場合とは異なり、修正を迫られる人は世界のどこにも存在しません。
Re:文字の幅 (スコア:0)
素朴な疑問。
UNIX統一仕様の一部である端末制御仕様の X/Open Curses では多カラム文字のための処理が定義されていて、 そこでは明らかに、locale DB によるカラム数情報を参照 することが意識されてるんだけど、そういった情報と 連動させるとかそういった話はないのかしらん?
特定の文字が端末において何カラムになるかというのは、 ロケール情報の一部であり、UNIX標準では wcwidth(3) で取得可能です。
まっとうな実装なら、端末も Locale 対応にして、 幅設定するには Locale DB を改変して
Re:文字の幅 (スコア:1)
はい。wcwidth(3) は知ってます。実際、 Robert Brady さんパッチを改良したぼくのパッチでは、wcwidth(3) を使っています。
これの最初の「不具合」は、 「en_US.UTF-8 ロケールでは wcwidth(3) の定義がいいかげんなので 自前でデータベースを持ったほうがいい」というもので、 そんなの、ロケール定義を実装すればしまいだろ、とか 思ったものです。が、それは無視するとしても、 wcwidth(3) そのものが移植性に乏しいとか (BSD なみなさん、がんばってください)、 リモート環境ではうまくいかないとかの問題が指摘されています。 ですので、 wcwidth(3) が正しく動くことは必要なことではありますが、 だからといってロケール定義を好き勝手にしてもきちんと動くという わけではないです。 ぼくはそれでも、リモートでない場合とか、自分で分かっててやるぶんには かまわないだろうと思うのですが...
あと、この XTerm に固有の問題ですが、 wcwidth(3) は wchar_t を引数にとる一方、 XTerm は内部コードとして Unicode を採用しているために 変換が必要になる、という問題があります。 Unicode とワイド文字の間の変換を、 移植性よく、効率よく書くにはどうすればいいのでしょうか? いちおう、上記のぼくのパッチには、それらしきコードが書いてありますが。 XTerm + luit のアプローチだと、XTerm そのものは エンコーディング変換を一切やらない建前だし (そうすることで XTerm 本体の保守性を保つのだとか。ぼくがメンテするのではないので、 そう言われると反論しにくい)、かといって luit はロケールを使わずに ISO-2022 をそのまま解釈する構造になっていて、 やはりワイド文字とかマルチバイト文字とかとはなじみが悪いです。 というわけで、wcwidth(3) に基づいた文字幅を実現するのは このままではなかなか難しそうです。
ところで、合成文字や bidi の場合は、wcwidth(3) はどのように動作すべきと 定められているのでしょうか?
Re:文字の幅 (スコア:1)
Single UNIX Specification では,wcwidth() は,ヌル文字 L'\0' の場合 0,非表示文字の場合 -1, その他の場合は文字幅を示す整数値を返すことになっています.BIDI や合成文字についての言及はありません.
もともと wcwidth() や,その導入の元になった column position (桁位置) という概念自体が,POSIX.2 の一部のユーティリティ (fold とか pr -w とか ls -C とか vi とか) にある「文字の桁幅」を意識した処理のためで,その定義も「ある行の中のある文字の桁位置は,その行の中で,その文字の前にある文字の桁幅の合計に 1 を加えたものと定義する」というくらいしか書いてなくて, 行の途中で文字の進行方向が変わったり, 他の文字と合成されて表示されるような文字があったりする場合は全く考慮されていません.
Re:文字の幅 (スコア:1)
ワイド文字のエンコーディングには××を使わなければならない,といった標準はないので (__STDC_ISO_10646__ が定義されていれば別ですが), 完全な移植性を求めるなら, 「いったん mbtowc() でマルチバイト文字に変換してから Unicode に直す」 しかありません.で,それは決して「効率よく」はない.
昔々,EUC が AT&T UNIX Pacific で規定された (厳密に言えば日本語 UNIX 諮問委員会の案を一般化しただけですが) ときには,マルチバイト文字とワイド文字との間の関係は完全に明文化されていたけれど,それは ISO/IEC 2022 の枠組みを強烈に意識していたので,その枠に収まらない Shift_JIS や Big5 での実現を排除してしまうことになり,それが標準になることもなかった.(実際 UNIX Pacific も, wchar_t を16ビットから32ビットにしたときに,ワイド文字の内部形式の互換はとらなかった.)
たとえば,HP-UX では EUC-JP も Shift_JIS も 両方サポートしていたけれど,ワイド文字の形式は UNIX Pacific 方式とは違っていて,しかも, たとえ同じ文字でも エンコーディングが違えばワイド文字の表現まで 変わってしまうのでびっくりしたことがあります. Solaris では一応 EUC-JP と Shift_JIS とでは 同じ文字のワイド文字表現は同じにしていましたが, UTF-8 になるとワイド文字が UCS-4 になってしまった ので,そういう意味での互換性はなくなりました.
ワイド文字が Unicode であることを明文化している システム (Windows NT の UCS-2 と glibc 2.2 の UCS-4) もありますし,たとえばマルチバイト文字の エンコーディングが UTF-8 の場合,wchar_t が32ビットなら,その内部表現が UCS-4 になるのが一番自然でしょうが,その想定が必ず正しいという保証はありません.たとえば,UTF-16 の範囲の文字しか使わないと思えば,上のビットが何ビットか余っていることになるので,それを別の用途に使いたいと思う人がいるかもしれません. (もっとも, Markus は wchar_t が Unicode でない実装を否定したいようですがね.)
Re: 文字の幅 (スコア:0)
これってDevanagariやThaiの扱いはどうなるんでしょ?
どんな仕様を提案するにしても、今日本人が欧米人に対して言うように、 後で「無知な日本人めっ」とか言われることになったら悲しいよね。
Re: 文字の幅 (スコア:1)
端末エミュレーターに限って言えば, 一文字が一定幅か,その整数倍の幅をもつという前提が (近似的にでも) 成り立たない文字に 適用するのはかなり困難でしょう. Devanagari や Thai がどうかは知らないので, なんとも言いかねます.
インド人やタイ人だってコンピューターを 使っているわけですから,勝手な思い込みで決めつけず,謙虚に意見を聞けばいいのです. 何にも知らないくせに, 「これなら世界中の文字に対応できる」とか, 「どうせ××文字なんて使うやつは少ないから, 後回しでいいんだ」とか, 偉そうに主張するのが一番嫌われる.
日本人なんておとなしいものですよ. なんせ,「これでは日本語が通らない」としか言わないのだから.
Re: 文字の幅 (スコア:1)
タイは、TIS620 というエンコーディングが使われており、結合文字が必須です。おそらくタイ人自身による実装である xiterm+thai というのが Debian では利用可能です。XTerm も UTF-8 モードではかなり前から結合文字の使用が可能です。これはタイ人じゃなくて Robert Brady さんという人の仕事です。ちなみに XTerm で全角文字が使えるようになったのも、この人のおかげです。
すみませんが、インドのことについては知りません。
「これでは日本語が通らない」としか言わないかというと、そうでもなくて、ASCII と CJK に対応したものを作って「国際化ができた」とか言うことがよくあります。
Re: 文字の幅 (スコア:1)
これは一本取られましたね. 「良くも悪くも,日本語のことしか考えていない」 という方が近いかな.
遠い外国の事情はわからないことが多いので, 「とりあえず日本語は通ります」といって出すのが いいのかもしれません.他の国の人が試して, 問題があれば直してくれるかもしれませんから.
日本語「も」使えます (スコア:1)
それでしたら、問題があるかどうか試してほしいという意思表示が必要だと思います。「とりあえず日本語は通ります」という言い方だと、「ああ、あれは日本語専用だからわれわれには関係ない」と思ってほっとかれるおそれがあります。
ぼくは、誇大広告になるのを覚悟で、「マルチバイト文字に対応するように改良した。CJK はマルチバイトが必要だし、将来 Unicode を使いたくなったら Unicode もマルチバイトだからこのパッチが役立つ。従来の 8 ビットエンコーディングには悪影響を与えないはずだからこのパッチを採用してくれ」とかいうふうに言うことにしています。