2010年01月02日

Ghostscript 8.70でのCJK表示 (メモ)

Debianのghostscriptに関しては、cmap-adobe-*でごちゃごちゃやるよりも、CMapについてはpoppler-dataにまとめたほうがよいと思う。gs-cjk-resourceも同じようなファイルを持っているのだがどうもわかりにくい。で、cmap-*とgs-cjk-resourceとdefoma(こいつが一番問題だ)を本当に捨てられるのか、試行錯誤中。

Debianのghostscript 8.70~dfsg-2ではまだfontconfig(FAPI)を使うようになっていない模様。この場合は次のような挙動になっていた。

  • 基本Postscript欧文Type1フォント(Nimbusなど): /var/lib/defoma/gs.d/fonts/Fontmapの参照マップから検索される。マップのファイル名はパスが付いていないので同一ディレクトリから検索される。defomaを使っている場合は/usr/share/fonts/type1/gsfontsの各pfbフォントへのシンボリックリンクが貼られているので、ここから拾われる。実際のところFontmapがなくても、最終的には/usr/share/fonts/type1/gsfontsが探索されてちゃんと処理されるけれども、ちょっと気持ちが悪いので絶対パス参照にしたFontmapを用意して、gsパスに入れるのがいいだろう。結局varかetcに何らかのファイルを置く必要がありそうだ。
  • CJK TT/OTFフォント: 昔Turbo/Axeで開発したらしきCIDFnmapやその他の修正は「パッチ当たらないので捨て」とchangelogに書かれていた(まぁよくあるパターン)。CMapは/usr/share/ghostscript/8.70/Resource/CMapが使われる。現在は/var/lib/defoma/gs.d/CMapへのシンボリックリンクになっていて、この中にcmap-adobe-*の各ファイルへのリンクがベタで置かれている。サブディレクトリは使えない。poppler-dataのファイルを流用できるが、ベタでリンクし直す必要がある。マッピングのキモは検索パスにもなっている/var/lib/defoma/gs.d/fontsのcidfmap。フォント定義、エイリアスの両方が記述されている。書式はこちらが参考になった。OTFはTT機能部分だけを使うことになる。defomaは動的にこれを生成しているが、fontconfigを使って何か……ということになったら結局似たものを作ることになっちゃいそう。静的でいいなら/Ryumin-Light、/GothicBBB-Medium、/Adobe-Japan1、/HeiseiKakuGo-W5Hにttf-japanese-mincho/gothic.ttfとでも書いちゃうという(ひどい)手もある。

レンダラにFreeTypeを使う「FAPI」という機構もある。DebianのデフォルトはOFF。FT_BRIDGEパラメータをDEB_BUILD_OPTIONSに付けて再ビルドすると有効になる。が、これで動かすのはどうもよくわからなかった。fontsにFAPIcidfmap、FAPIconfig、FAPIfontmapの3つのファイルを置いて調整するようなのだが、文字のないPSですら起動しない。単にレンダラなだけでFreetypeのフォント名が使えるわけでもないし、メリットがわからない。

FAPI/fontconfigはとりあえず無視？ CJKについては、cmap-*/gs-cjk-resourceは捨ててpoppler-dataに統一してもよさそう(gs-cjk-resourceのSMgoJが気になるが)。ただし、ghostscript用にCMapのベタ展開と、cidfmapの何らかの管理は必要。poppler-dataでやる話ではないので、何か別のパッケージを用意する必要がある(gs-cjk-resourceを作り変える？でもupstreamとは何の関係もないものになるので、名前を変えたほうがいいのではないか)。欧文Fontmapについてはgsfontsかghostscriptかで面倒を見るのがよさそう。

もうちょっと見てみた(2010.1.2 16:16)。また別にfontconfigを使う箇所があって、これはHAVE_FONTCONFIGフラグでデフォルトで有効になっており、FT_BRIDGEとは関係ない。設定はbase/gp_unix.cに反映され、fontconfigで管理しているフォントファミリとスタイルからPSフォント名をマングルして生成するmakePSFontNameという関数が有効になる。また、unix_fontenum_tというfontconfig接続構造体が追加され、gp_enumerate_fonts_init関数にはfontconfigの設定を読み込んでフォント一覧を取得するコードが追加される(エイリアスは読まれるんだろうか？デバッガで追わないとよくわからない)。gp_enumerate_fonts_next関数には順次フォントを読んでmakePSFontNameを使いPSフォント名とパスを返すコードが入ってるっぽい。gp_enumerate_fonts_free関数には掃除コードが追加。

結局、代表PSフォントのエイリアスをやってくれるわけではないっぽいので、これは引き続きfontconfigにエイリアスマップを記述することになりそう。逆に言えばこれだけが現状の問題？本当にfontconfigの探索がうまくいくか実験してみよう……。

……だめげ。和文については、makePSFontNameで「VLゴシック-Unknown」とか返してきちゃってる。LANG=Cにすれば一応英語名が先に返るようにはなる。欧文についても、gp_enumerate_fonts_nextで実ファイルしか探さないので、fontconfigでのエイリアスは効果がないっぽい(エイリアスはFontmapかcidfontmap側)。しかしそもそもPSファイルでPSフォント名をどのように書いても、ファイルが読まれないっぽい感じ。

リンク [hatena] | Debian