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

[debian-devel:16693] East Asian Width Problem at rxvt-unicode-ml

dai と申します。

# debian-devel@jp で聞くのは場違いかもしれませんが...。

rxvt-unicode-ml を ja_JP.UTF-8 locale 上で動作させたときの
文字幅についての質問です。

Debian Official に入っている rxvt-unicode-ml 7.9-2 において、
ja_JP.eucJP locale にて「×」や「±」といった
いわゆる全角の文字の記号がいわゆる半角の幅で扱われてしまう問題は、
upstream の 8.1 にて直していただきました [1]。

ところが ja_JP.UTF-8 locale では、依然として「×」や「±」の
表示が乱れる問題が存在しています。
調べてみたところ、これらの記号は Unicode の EastAsianWidth 属性の値が
Ambiguous となっており、その文字幅は文脈依存とわかりました。

そこで、East Asian Ambiguous な文字について、
良きにはからってくれるような修正 or 機能追加をお願いしたのですが、
rxvt-unicode 作者氏には完全に拒否されました [2]。

頂いたメールから読み取った rxvt-unicode 作者氏の考えをまとめると、

* rxvt-unicode は locale が指定した文字幅を尊重している。
  プログラムは locale の指定に従うべきで、そうしないのはバグである。

* libc ではなく、vim や xterm などあらゆるプログラム側で、
  locale の制限のためにこのような修正をしなければならないのはナンセンス。

* 正しい locale を用いるか、locale を修正すべき。
  または libc が EastAsianWidth の文字幅のような、
  詳細を設定する手段を提供すべき。
  そうすれば locale を尊重している正しいプログラムは
  きちんと動作するようになる。

* このような理由で Markus Kahn's wcwidth() 実装 [3] は buggy である。

とのことのようです。

localedef が locale 生成の際に使用する UTF-8 charmap は
/usr/share/i18n/charmaps/UTF-8.gz のようですが、これを見ると、

% Character width according to Unicode 3.2.
% - Default width is 1.
% - Double-width characters have width 2; generated from
%        "grep '^[^;]*;[WF]' EastAsianWidth.txt"

となっており、デフォルトの文字幅は 1 で、EastAsianWidth が
WIDE (W) か FULLWIDTH (F) の文字幅のみ 2 と設定されているようです。
よって、Ambiguous (A) な文字幅が 1 となり、
rxvt-unicode 作者氏が言うところの「buggy な修正」が必要になっているようです。
試しに UTF-8.gz に Ambiguous (A) な文字幅も 2 になるように
エントリを追加して locale を作り直したところ、
rxvt-unicode-ml は修正なしで期待通りの文字幅で表示するようになりました。

このように、現状では色々困ったことになっているので
BTS するなり upstream に報告するなりしようかと思っているのですが、
いくつかご意見をお聞かせください。

* rxvt-unicode 作者氏の言うとおり、glibc に BTS する。
  - EastAsianAmbiguous な文字の幅を指定できる機能追加。
  - EastAsianAmbiguous な文字の幅を 2 とした charmaps を作り、
    ja_JP.UTF-8 はそちらを使って locale を作るように。

* rxvt-unicode-ml に BTS する。
  - Markus Kahn's wcwidth() 実装に相当するものを Debian 独自に追加。

考え方などが根本的に間違っているとか、
実は BTS するまでもなく回避方法が既にあるなど、
突っ込み所やポインタなどあれば教えていただければ幸いです。

Regards,
-- 
	dai

[1] http://lists.schmorp.de/pipermail/rxvt-unicode/2006q4/000347.html
[2] http://lists.schmorp.de/pipermail/rxvt-unicode/2007q1/000402.html
[3] http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c