Re: w3mmee with utf-8

[hsaka@xxxxxxxxxxxxxxxxx (Hironori Sakamoto)]

坂本(浩)です。
# emacs とあんまり関係なくなっちゃいますけど。

> From: Kiyokazu SUTO <suto@ks-and-ks.ne.jp>
> > w3m-m17n (の UTF-8 出力)も xterm に合わせているのですが、
> > これは EastAsianWidth.txt で属性が "W" か "F" のもののみ width=2
> xterm-147までだともう少し複雑怪奇な状態だったような。最近のバージョン
> で変わったとすると由々しき事態。

xterm-150 だと、Markus Kuhn 氏作の
    ((ucs >= 0x1100 && ucs <= 0x115f) || /* Hangul Jamo */
     (ucs >= 0x2e80 && ucs <= 0xa4cf && (ucs & ~0x0011) != 0x300a &&
      ucs != 0x303f) ||                  /* CJK ... Yi */
     (ucs >= 0xac00 && ucs <= 0xd7a3) || /* Hangul Syllables */
     (ucs >= 0xf900 && ucs <= 0xfaff) || /* CJK Compatibility Ideographs */
     (ucs >= 0xfe30 && ucs <= 0xfe6f) || /* CJK Compatibility Forms */
     (ucs >= 0xff00 && ucs <= 0xff5f) || /* Fullwidth Forms */
     (ucs >= 0xffe0 && ucs <= 0xffe6));
ですね。
# ベタなハードコーディング…
# でも最初は全部同じ幅だったからなぁ。あれは酷かった。
さらに、Robert Brady 氏＆久保田さんの patch で CJK向け("A" も 2)
とシステムの API の wcwidth を使うオプションも追加されており、
取り込まれるのを待っている状態と思います。
# が、最近 『Set Character Width Proposal (Version 3)』と題して
#   http://mail.nl.linux.org/linux-utf8/2001-06/maillist.html#00106
# また、ごちゃごちゃやっている様です。

> 実際の問題は、w3m{-m17,mee}の変換とMuleの変換が必ずしも一致しない(デフォ
> ルトは一致しない、さらにユーザの設定次第で変更可能)という点のようです
> ね。1文字単位で指定可能にするオプションが必要なのかも。

Mule を前提なら ISO 2022 系で出した方がすっきりすると思いますが、
ISO 2022 に無い文字はどうすればいいんだろ。(Mule-UCS はどうしてるんだろ)

# 個人的には Unicode で文字幅云々はきっちり出来ないもんだと諦めてます。
-----------------------------------
坂本 浩則 <hsaka@mth.biglobe.ne.jp>
 http://www2u.biglobe.ne.jp/~hsaka/