ghostscript-gplで高速日本語表示

これまで機嫌よくghostscript-gnuを使っていたが、evinceを使ってみようとしたら、print/libspectreのビルドでWITH_GHOSTSCRIPT_GNUは設定するなと文句を言われ、しかたなくghostscript-gpl (8.62)に移行してみることにした。フォント設定はほっておいてもIPAフォントで日本語が表示されるようになっていたが、デフォルト設定では、以前のafpl版8.54と同じく、その日本語表示が非常に遅い。

オプションをよく見ると、FT_BRIDGEという設定が可能で、TrueTypeフォントのレンダリングにFreeTypeを使ってくれそうな気配である。うまくいけば、7.07くらいに高速に表示してくれるかもしれない。そこで、これを設定し、FAPIcidfmapをいじって、

/Ryumin-Light << /Path (/usr/local/share/ghostscript/fonts/Ryumin-Light.ttf) /CIDFontType 0 /FAPI /FreeType /CSI [(Japan1) 2] >> ;
/GothicBBB-Medium << /Path (/usr/local/share/ghostscript/fonts/GothicBBB-Medium.ttf) /CIDFontType 0 /FAPI /FreeType /CSI [(Japan1) 2] >> ;

としてみたが、日本語フォントを表示させるところでSegmentation faultを起こしてしまった。

gdbのバックトレースなんかで調べてみたところ、どうやら、FAPI_do_char()がcid_to_TT_charcode()を呼ぶところで、TT_cmapというパラメータをNULLにして渡しているのに、その中で呼ばれているTT_char_code_from_CID_no_subst()が何も考えずにarray_get()にTT_cmapを渡してしまっているのが原因っぽい。だからといって、array_get()を呼ばなくしてみると、日本語の文字がまったく表示されなくなって使いものにならない。いろいろ調べたところ、gsの古いcvsの記録から、最初にこのあたりのコードを加えたときにはTT_cmapがNULLの時の処理が含まれていたのに、あとからそのコードが消えていることがわかった。

なので、同じようにTT_cmapの判定コードを加えたところ、Segmentation faultを起こすこともなく、しかも以前よりちょっと遅いかな程度に高速に日本語を表示できるようになった。

ただ、どうも多量にWarningが出るので、まだどこか完全じゃないんだろう。


追記（5/29）

FreeTypeを使うと、縦書きが使えないことが判明。

デフォルトでは、article9.psみたいな縦書きPSファイルを表示させると、括弧とか句読点とかの約物に横書き用をそのまま使ってしまうという問題があるものの、まずまず見られる表示になる。しかし上の方式だと、縦のベースラインがぐちゃぐちゃになって（文字の左側を揃えている感じだけどそれでもおかしい）、しかも一部の文字が歯抜け状態になり、実用にならない。うまくいかないものだ。