kochi-ttfonts更新でlinux-flashplugin7に漢字出ず

japanese/kochi-ttfontsが更新されたので、そのままportupgradeしたら、FirefoxのFlash Playerプラグインに漢字が出なくなった。例の/usr/local/lib/X11/fs/configはちゃんとハックしてあるし、どうしたことかと悩む。

ファイルアクセスの時刻を見てたら、Flashを動かすと、fonts.dirは読み込まれるのだが、kochi-gothic-subst.ttfが読まれた形跡がない。x11-fonts/cyberbit-ttfontsを入れてみると、こちらが表示されるが、字形が気に入らないので、これは避けたい。で、両者のfonts.dirに何か差があるのか眺めていたら、Cyberbitの方は、fonts.dirの左辺に書くファイル名にいっさい修飾がない。kochiの方はすべての行がTTCap拡張による修飾付きである。更新せずに放置しているFreeBSDの仮想環境と比べたら、そちらはkochiについても、修飾なしの行が含まれていた。

おそらく、libflashplayer.soはfonts.dirを自力で直接解析していて、TTCapの書式を理解せずに全体をファイル名とみなしてしまい、正しいファイルを開けなかったのだろう。なので、適当な行をfonts.dirに加えればうまくいくはず。ついでに、東風フォントじゃなくてIPAフォントにしてしまえるはず。というわけで、fonts.dirに以下の行を追加。

ipamp.ttf -kochi-mincho-dummy-dummy-dummy--0-0-0-0-p-0-dummy-0
ipagp.ttf -kochi-gothic-dummy-dummy-dummy--0-0-0-0-p-0-dummy-0

FoundryとFamilyしか見てないっぽいので、あとはダミーにしておいた。

以上で、Flash上でもIPAフォントがちゃんと表示されることを確認。これでja-kochi-ttfontsに依存するのは、ja-xpdfだけになった。こいつさえ修正できれば、kochiを消せる。いつかやろう。


追記（6/3）

ふたたびkochi-ttfontsが更新されて、fonts.dirをいじる必要がなくなった。というか、kochi-ttfontsを入れたり消したりすると、-kochi-の含まれる行がfonts.dirから勝手に削除されてしまうことがわかった。適当にディレクトリを作って、そこだけ見るようにfs/configをハックした方がいいのかもしれない。

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