AA自動作成ツール(途中)

前回AA作成ツールを修正すると書き、この記事を書くまで試行錯誤をしていた。

今回はその中身を書いていく

 

前回までのはC言語で作成していた。AA化のアルゴリズム自体に不備は無かったんだけど画像を読み込むときとか十分に大きく取った配列に画像を読み込むとかいう変なことをしてたので可変長配列を扱いやすいC++で書き直した。

それで書き直すついでにアルゴリズムの手順ひとつひとつを関数化してどこが問題になってるか原因をわかりやすくした。

 

特定できた原因は

・GetGlyphOutline関数

これだ。

 

これは与えた文字のビットマップを返してくれるwin32apiで用意されている関数なんだけど結構いろんな記事でバグがー、罠がーといわれている。私も例に漏れずかかってしまった。

 

帰ってくる処理結果は以下のような図になる。

GetGlyphOutline関数のフォント位置 様より勝手に参照

 

f:id:akikanR:20170603193907j:plain

 

gmCellIncXが文字の空白も含んだXのサイズで
gmBlackBoxXが空白を含まないXのサイズ
gmGlyphOrigin.xがgmCellIncX上での文字の起点のX座標だ

この理解が間違えてなければgmCellIncX >= gmBlackBoxXは常に成り立つはずだ
これがまず変になってしまう
jをGetGlyphOutline関数に与えると

gmCellIncX >= gmBlackBoxXの関係が崩れる
というかgmGlyphOrigin.xなんか負の値が帰ってくる

ためつすがめつ見てみると以下の関係が見えてきた

gmCellIncX = gmBlackBoxX + gmGlyphOrigin.x

どのような文字をGetGlyphOutlineに与えようとこの関係だけは不変だった

 

 文字の横幅のサイズが保証されなくなってしまったために上記の横幅を示す3要素をいじって試すかしかなくなってしまった

とりあえず試したのが上の等式を変形したこの形

 gmBlackBoxX = gmGlyphOrigin.x  -  gmCellIncX

上の画像の関係が割りと怪しくなってるのでその関係を持ち出すのは正直意味無いと思うが他にリファレンスもないので頼ると横幅のサイズはgmBlackBoxXよりも小さくはならないのでまぁやってみる

 

f:id:akikanR:20170603214924p:plain

知ってた(白目)

他にも手がないし・・・ってことで gmCellIncXだけを横幅として試してもみたがダメだった。

後ちょっとで出来そうな気もするがちょっと仕様がよくわからんようなものを使ってたく無いので別の手法で試します。