East Asian ambiguous characters

5/10の続き。恐ろしく根が深い。ambiguous characterの表示幅を端末側で2としてしまうと、その上で動くAPが表示幅=1だと思っている場合に不整合が生じる。w3mの表示は桁ズレ出まくり。やはり、rxvt作者が言う通りlocaleがambwidthを提供する仕組みが必要なのだ。とは言っても、とりあえずw3mの桁ズレは解決したい。cvs版に対するambwidth patchがあるので、これを最新の0.5.2に当ててみた。「ある種のUnicode文字を全角にする」、全く意味のわからない文言だが、このオプションを有効にすることで2行にまたがっていた<hr>は1行になった。が、bookmarkでリンクにカーソルを移動すると1桁ずれる。どうやら<li>に使われている文字の文字幅の認識が端末とw3mでずれているらしい。ここで漸く<li>が豆腐に化けていることが問題であることに気づく。「全角にする」が有効になっていれば<li>の文字は全角のはずなのに、豆腐だから半角になってしまっているのだ。
さらに調べてみると、gnome-terminalなら表示できるのにmltermでは表示できない文字が軒並ある。こんな大問題が放置されているはずもないが、情報はない。~/.mlterm/aafontを削除してみると表示できなかった文字は全て表示され、w3mの桁ずれも完全になくなった。そこで/etc/mlterm/aafontを元に~/.mlterm/aafontを再作成することに。この過程でわかったことだが、ISO10646_UCS2_1に対してM+などの日本語を含むフォントを指定すると、表示できない文字が生じるらしい。試行錯誤の結果、aafontは

ISO10646_UCS2_1=DejaVu Sans Mono-iso10646-1:120;
ISO10646_UCS2_1_BIWIDTH = M+2VM+IPAG circle-iso10646-1;

このように。M+のISO-8859部分はDejaVu Sans Monoのはずなのだが(実際、上記の状態で半角にもM+を使った場合と見た目には区別がつかない。表示できない文字以外には)、DejaVu Sans Monoを使った場合は、文字ピッチを表す最後の"120"を指定しないと、妙に横広がりになってしまう。
これで半角に指定できるOsakaフォントがあれば文句無いのだが。