坂本です。
> 久保田です。
> mlterm と w3m の組み合わせで、不具合が見付かりました。どちらに原因が
> あるか、よくわかりません。
> w3m 0.2.1-inu-1.4a2-0915 というのを使っているのですが、
> LANG=ja_JP.eucJP 以外で「o」を押してカスタマイズモードに入り、次いで
> 「B」などを押して抜けると、ASCII 以外の文字が化けることに気付きました。
> これは、罫線文字を表示するためのコードが原因のように思われます。と
> いうのは、画面サイズを小さくして、罫線 (26行目) を表示しないように
> すれば、不具合は起こらないからです。
w3m のコンパイルオプションを教えてくださいませんか。
# 現象から、#define LANG JA かつ #undef KANJI_SYMBOLS だと
# 思いますので、それを前提に話を進めます。
w3m (などのコンソールアプリケーション)は termcap から eA, as, ae, ac
を得て罫線(alternative (graphic) charset)を表示しています。
eA, as, ae には良く使われているパターンとして、
* eA = ESC ) 0, as = ^N, ae = ^O
eA で G1 に alternative charset を指示しておいて、
as で GL に呼び出して使い、ae で G0 を GL に呼び戻す。
* eA = 無し, as = ESC ( 0, ae = ESC ( B
as で G0 に alternative charset を指示しておいて、
GL で使い、ae で G0 への指示を ASCII に戻す。
があります。
# 手元では xterm-r6 が前者、XFree86 xterm は後者です。
化ける場合は、おそらく前者の方だと思います。
理由は、GR に呼び出されている G1 の文字集合(EUC-JP なら JIS X 0208)
を eA で変えているのに、ae で戻していないからです。
ESC ) 0 を ISO 2022 の拡張として処理する端末なら、化けるべくして
化けるわけです。
# 本来の終端文字は 0x40(@)〜0x7E(~)の範囲なので、終端文字としての
# 0x30(0) は ISO 2022 には従っていない。
端末の仕様と termcap のミスマッチの結果ですので、
mlterm 側では自前の termcap を用意して後者の設定に固定するのが、
本質的な解決策と思います。
ESC ) 0 での G1 への指示は GL に呼び出した時にのみ有効とする
次善策もありますが、ISO 2022 パーサに特殊処理が入るので、
嫌なのですよね ＞ 荒木さん
# 指示されている charset を初期値に戻すコントロールシーケンスが
# termcap にあればいいのですが、なさそうですし。
# w3m 側では諦めています。w3m-m17n でも、あがいたけれど諦めました。
# そうそう、こういう化けた後 mlterm だと ISO 2022 を理解していないと
# 自分では復帰できないので、kterm のメニュー(Ctrl+中ボタン)にある
# Do Full Reset 相当の機能が以前から欲しかったのでした。
# mlconfig に加えられませんか？
# ついでに、mlcofing で Apply, Cannel だけでなく、
# OK (現行の Apply), Apply (mlconfig を終了しない), Cannel
# として欲しいです。
# 実は、mlconfig は configuration の結果を save できないので、
# mlcontrol なのかなと思っていたり(^^;
-----------------------------------
坂本 浩則 <hs...@mt...>
http://www2u.biglobe.ne.jp/~hsaka/
|
