少しだけ解析

プログラム xyzzy

概要

国際化対応に関してxyzzyをちょっと解析。
xyzzyは国産の中では最も技術力が高いと言われているような気もするので、最も特殊な処理を行っている気がしてあえて少し調べる事にした。
寝る前にその解析した結果をメモ。そのうちまとめる。
そのうちまとめる事がなんだか溜まってきたが。

描画部分の調査

disp.ccがほぼ全て行っているっぽい。
手元のソースだと565行目にあるWindow::paint_glyphs関数から、paint_charsを呼んで、さらに文字種別によってpaint_ascii_chars、paint_jp_chars、paint_full_width_chars、paint_half_width_chars、paint_jisx0212_half_width_chars、paint_chars_lucidaに飛ばしている。
jpとasciiはExtTextOut関数で描画。
それ以外は、ExtTextOutWを内部的に呼んでいる（正確にはpaint_chars_ctxのpaintを呼び、その中からExtTextOutW）。この際、paint_chars_lucidaだけDeleteObjectを毎回行っている。実は少し苦手な部分なのだろうか。
xyzzyが固定ピッチで収まっているのは、ExtTextOut（またはExtTextOutW）で描画可能矩形を指定してロシア語とかも丸めているのかな、と思ったが・・。
さすがにWizardクラスのソースだ。ぱっと見だとpaint_glyphs関数のこの処理がわかんない。

char *be = buf;
const glyph_t *g0 = g;
glyph_t c0 = *g++;
*be++ = char (c0);
glyph_t c = c0 & (GLYPH_FORE_COLOR_MASK | GLYPH_BITMAP_BIT
                  | GLYPH_CHARSET_MASK | GLYPH_BOLD);
〜中略〜
if (c & GLYPH_BITMAP_BIT)
〜中略（なんかhdcmemからhdcにBitBltしてる）〜
else
  paint_chars (hdc, r.left, y, ETO_CLIPPED, r, GLYPH_CHARSET (c),
               buf, be - buf, padding);

paint_charsに渡している「c」が文字種別の判別に使われているっぽい。
be - bufが描画文字数なのだが、、わ、わからん。
しかし変数名短ぇぇ・・。

結論

出したいけど2時間くらい眺めて理解出来る代物ではなかったので保留。ビルド環境整えないと、今の私のレベルで完全理解は苦しいな。
ただ、固定ピッチ専用処理を書いているので、プロポーショナルしかない言語圏がもし存在したら、そもそもxyzzyがサポートすべきでない言語圏が存在する、というのは事実だと思われる。アラビア語はどうなのだろう。
EmEditorのアプローチも真魚のアプローチも面白いのだが、まあ、ルーラーを表示するタイプのエディタでのプロポーショナルフォント処理で、正解はなんなのかというのはよくわからない部分もある。
真の意味でのi18nエディタというのは、またの機会に考えた方がよさそうだ。アラビア語対応に限った記事を後日清書するに留めるとしよう。