アカウント名:
パスワード:
フォントだけでは決まりません。XFree86 XTerm の実装では、半角用フォントと全角用フォントのふたつを用意して、文字ごとにどちらかを使うというふうになっています。
文字幅が重要なのは、たとえば tcsh の漢字サポート版では、漢字を入力した後に BS キーや ← キーを押すと、2 文字分のカーソル移動コントロールコードが出力され、kterm や rxvt などの動作とマッチするようになっています。つまり、すべてのプログラムで統一した解釈になっている必要があります。
もし現在のその統一された動作が変だから変更しようというのなら、世界中のプログ
素朴な疑問。
UNIX統一仕様の一部である端末制御仕様の X/Open Curses では多カラム文字のための処理が定義されていて、 そこでは明らかに、locale DB によるカラム数情報を参照 することが意識されてるんだけど、そういった情報と 連動させるとかそういった話はないのかしらん?
特定の文字が端末において何カラムになるかというのは、 ロケール情報の一部であり、UNIX標準では wcwidth(3) で取得可能です。
まっとうな実装なら、端末も Locale 対応にして、 幅設定するには Locale DB を改変して
はい。wcwidth(3) は知ってます。実際、 Robert Brady さんパッチを改良したぼくのパッチ [debian.or.jp]では、wcwidth(3) を使っています。
これの最初の「不具合」は、 「en_US.UTF-8 ロケールでは wcwidth(3) の定義がいいかげんなので 自前でデータベースを持ったほうがいい」というもので、 そんなの、ロケール定義を実装すればしまいだろ、とか 思ったものです。が、それは無視するとしても、 wcwidth(3) そのものが移植性に乏しいとか (BSD なみなさん、がんばってください)、 リモート環境ではうまくいかないとかの問題が指摘されています。 ですので
ところで、合成文字や bidi の場合は、wcwidth(3) はどのように動作すべきと 定められているのでしょうか?
Single UNIX Specification では,wcwidth() は,ヌル文字 L'\0' の場合 0,非表示文字の場合 -1, その他の場合は文字幅を示す整数値を返すことになっています.BIDI や合成文字についての言及はありません.
もともと wcwidth() や,その導入の元になった column position (桁位置) という概念自体が,POSIX.2 の一部のユーティリティ (fold とか pr -w とか ls -C とか vi とか) にある「文字の桁幅」を意識した処理のためで,その定義も「ある行の中のある文字の桁位置は,その行の中で,その文字の前にある文字の桁幅の合計に 1 を加えたものと定義する」というくらいしか書いてなくて, 行の途中で文字の進行方向が変わったり, 他の文字と合成されて表示されるような文字があったりする場合は全く考慮されていません.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
文字の幅 (スコア: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 さんパッチを改良したぼくのパッチ [debian.or.jp]では、wcwidth(3) を使っています。
これの最初の「不具合」は、 「en_US.UTF-8 ロケールでは wcwidth(3) の定義がいいかげんなので 自前でデータベースを持ったほうがいい」というもので、 そんなの、ロケール定義を実装すればしまいだろ、とか 思ったものです。が、それは無視するとしても、 wcwidth(3) そのものが移植性に乏しいとか (BSD なみなさん、がんばってください)、 リモート環境ではうまくいかないとかの問題が指摘されています。 ですので
Re:文字の幅 (スコア:1)
Single UNIX Specification では,wcwidth() は,ヌル文字 L'\0' の場合 0,非表示文字の場合 -1, その他の場合は文字幅を示す整数値を返すことになっています.BIDI や合成文字についての言及はありません.
もともと wcwidth() や,その導入の元になった column position (桁位置) という概念自体が,POSIX.2 の一部のユーティリティ (fold とか pr -w とか ls -C とか vi とか) にある「文字の桁幅」を意識した処理のためで,その定義も「ある行の中のある文字の桁位置は,その行の中で,その文字の前にある文字の桁幅の合計に 1 を加えたものと定義する」というくらいしか書いてなくて, 行の途中で文字の進行方向が変わったり, 他の文字と合成されて表示されるような文字があったりする場合は全く考慮されていません.