Home

Awesome

kage-engine-compare

@kurgm/kage-engine をリファクタリングするにあたって出力される字形に変化が発生していないか確かめるため、グリフウィキ上の全グリフについて変更元のコードの出力字形と比較するスクリプト

A script to compare the glyph shapes generated from the refactored code @kurgm/kage-engine and the original code

@kurgm/kage-engine はオリジナルの KAGE エンジンからフォークしてコードの整理を行っています。その際に同じ入力 KAGE データに対する出力が変わってしまうと困るので、このスクリプトは出力結果が変わっていないことを確かめます。

なぜ困るかといえば、グリフウィキではサーバ側での画像生成ではオリジナルの KAGE エンジンが使われている一方、クライアント側で動作する字形エディタ kage-editor では @kurgm/kage-engine を使っているので、これら 2 つの間で出力結果が変わることは kage-editor で作った字形とサーバ側で生成される字形が変わってしまうことを意味するからです。

とはいえコードの見通しをよくしたり処理を高速化するために計算手法・計算順序を変えると、ところどころで出力結果に誤差が生まれます。現状 KAGE エンジンが出力するポリゴンは点の座標値を 0.1 の倍数に丸めていますが、丸める前の値がしきい値付近（たとえば 100.0999999… など）にあるとごく僅かな誤差が座標値に 0.1 のずれを生み出す場合があります。そしてこのずれた座標値を使って計算した値をさらに丸めることで、ずれが 0.2, 0.3, … に広がる可能性もあります。

しかし座標値の 1 未満の差異は、出力画像の一辺の長さが 200 であることを踏まえればその 0.5% 未満であり、わざわざ字形を重ねたりして比較しない限りは変化を知覚することはほぼできません。そこで、ある程度の小さな差異は許容することにしてコードの整理を行うことにしました。ここで、整理の前後で出力字形を比較したときの差異について、許容する基準を次のとおり定めます。

ただしコード整理前の字形として比較対象とするのは、オリジナルの KAGE エンジンではなく orig_node ブランチのプログラムの出力字形を使います。orig_node ブランチでは if 文などの条件分岐で整理後のコードと同じ分岐が選ばれるように最低限の箇所（条件式に現れる浮動小数点数の比較演算）に丸め処理を追加しています。 <small>（この点では、オリジナルの KAGE エンジンと出力を比べたときに上の基準を超える差異が生じうることになりますが、そのようなケース自体が（同じエンジンでも）僅かな計算誤差で出力が大きく変わりやすい、いわば本質的に“敏感な”入力データであるということになり（たとえばグリフウィキでいう実体とエイリアスとで画像が違ったりする場合がある）（たぶん）、そういう“敏感な”入力ならコードの整理で出力に差異が出てもいいでしょ、って思うことにしてます。裏を返せば、“敏感でない”入力に対する出力に差異が出ていないか効率的に検査するためこのような比較をしています。）</small>

またこのスクリプトは、機能追加・バグ修正など出力字形に積極的に変化を及ぼすような変更を KAGE エンジンに加える際に、グリフウィキ上の既存のグリフの字形にどのような変化が起こるかを調査するためにも役立つはずです。コードの修正によって意図した方向に字形が変わるか、そして特に非漢字グリフ（や一部の“変な形”を含む漢字グリフ）は KAGE エンジンが元来想定していない種類のデータを含むことがあるので、それらに副次的な影響が生じないかを全グリフについて調べることには一定の価値があります。