このページは過去に掲載していたものをそのまま使用しています。
PNG出力での日本語サポートはコードを追っていけば それほど難しくはない問題だと思います。
Diaでは出力をする仕組は基本的に画面に出力する方式と同じです。 つまり「この点からあの点まで直線を引く」関数が呼ばれます。
... renderer->ops->draw_line(renderer, &p1, &p3, &color_black);
この引数に含まれているrenderer
がポイントになる構造体です。
その基本的な構造は$DIR_ROOT/lib/render.hで記述されています。
この構造体は、もうひとつRenderOps
という構造体を持ち、この
中に自身を操作できる関数群を持っています。
具体的なrenderer
の実装は$DIR_ROOT/app/render_XXX.cに
あります。XXXには、そのrenderer
の機能を表現するような
具体的な名前がつけられています。たとえばrender_eps.cのように。
PNG出力を表現するような名前のrender
は存在しませんが、
render_libart.cというのがそれです。これはexport_png.cと
対になって使われます。render_libart.cの方はPNG出力以外のbitmap出力
でも使えるために別にされているように思われます。
前置きが長くなりましたが、このrender_libart.cで定義されている
render
を操作することでPNG出力の様相を変化させる事ができます。
今回はdraw_string()
関数を変更する事で日本語の出力を可能に
しています。
さてこのdraw_string()
関数では何が行なわれているのでしょう。
SuckFont
の取得
suckfont
からビットマップ情報を取り出す
問題はこのsuckfont
が、実質的にASCIIコード(8bits)分の
ビットマップデータしか保存していない点にあります。日本語文字列を描画
しようと思っても、ビットマップデータが存在しないために何も出力されません。
(日本語を含む文字列は処理はされるが描画すべきデータがない、
- サイズ0の文字データ -、 ので、ASCII文字のみが詰めて描画される)
日本語の文字すべてについてビットマップ情報を持つ事は効率的では ありません。そこでこのビットマップをキャッシュしている部分を改造して、 動的にデータを取得するように改造する事にしました。
具体的にはgdk_draw_text
によって生成していたビットマップ
データをgdk_draw_string
で取得するように変更しただけです。
さらに$DIR_ROOT/lib/font.cで定義されている関数を
$DIR_ROOT/app/render_libart.c内の関数として、描画するテキストに
依存したビットマップを生成するようにしました。