アカウント名:
パスワード:
フォントだけでは決まりません。XFree86 XTerm の実装では、半角用フォントと全角用フォントのふたつを用意して、文字ごとにどちらかを使うというふうになっています。
文字幅が重要なのは、たとえば tcsh の漢字サポート版では、漢字を入力した後に BS キーや ← キーを押すと、2 文字分のカーソル移動コントロールコードが出力され、kterm や rxvt などの動作とマッチするようになっています。つまり、すべてのプログラムで統一した解釈になっている必要があります。
もし現在のその統一された動作が変だから変更しようというのなら、世界中のプログ
素朴な疑問。
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 でない実装を否定したいようですがね．)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
文字の幅 (スコア:0)
ではないんですかね。従来の US-ASCII:JIS X 0208 =
1:2 が欲しいなら、そういうフォントを使えばいいの
では…
従来の文字幅が欲しいなら kterm を使えばいいわけだし、
どうでもいいじゃないですか。
Re:文字の幅 (スコア:1)
フォントだけでは決まりません。XFree86 XTerm の実装では、半角用フォントと全角用フォントのふたつを用意して、文字ごとにどちらかを使うというふうになっています。
文字幅が重要なのは、たとえば tcsh の漢字サポート版では、漢字を入力した後に BS キーや ← キーを押すと、2 文字分のカーソル移動コントロールコードが出力され、kterm や rxvt などの動作とマッチするようになっています。つまり、すべてのプログラムで統一した解釈になっている必要があります。
もし現在のその統一された動作が変だから変更しようというのなら、世界中のプログ
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 でない実装を否定したいようですがね．)