From: <hs...@mt...> - 2002-01-03 13:05:34
|
坂本です。 > 久保田です。 > 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/ |