2005年11月11日

gs-esp 8.15.1.dfsg.1-1日本語周り

ひさびさにmhattaさんがアップロードしたので、試してみる。が、以前の問題はまだ解決付いてないなぁ(まぁeasyswのSTRに出さないと駄目か)。現状etch/sidで日本語表示する手順は次のような感じ？(昔出したFontmap編集はもう使わなくなったので必要ない)

  1. gs-esp, gs-cjk-resource, cmap-adobe-japan1, ttf-sazanami-mincho, ttf-sazanami-gothicをインストール。kochiフォントはダメ。
  2. dpkg-reconfigure cmap-adobe-japan1を実行して、チェックボックス3つ全部を有効にする。
  3. -dSAFER、-dPARANOIDSAFERが付いていると日本語フォント周りで見つけられない旨のエラーが出てしまう。gvならState→Ghostscript Options→Saferのチェックを外す→Save→Dismissとすれば、~/.gvに書き込まれて-dSAFERが無効になる。
  4. CUPSの場合は、/etc/cups/ppd/にある該当プリンタのPPDファイルを見て、-dSAFERまたは-dPARANOIDSAFERがないかを確認する(多分*FoomaticRIPCommandLine)。見つかったら-dSAFER/-dPARANOIDSAFERの文字列を削除する。

という感じで、-dSAFER、-dPARANOIDSAFERを外すのはいかにもアレなので困る。Debianのほうにはバグ報告してみた(easyswに言ってもgs-cjk-resourceは知らんと言われそうだな…。gs-cjk-resourceの問題なんだろうか)。

しかし、中国韓国なども同じ問題を抱えるわけで、gsが使えないと困りそうなものなのだけど苦情レポートを見たことがない。どうやって印刷しているんだろうか？

問題追跡中。はて、なんでSAFERを付けると、ttf/ttcファイルをstat64したあとに「フォントパス/CMap/r」をopenしようとするんだろう？SAFERがない場合、openされるのは直にttf/ttcファイル。

gs_init.psの.setsafeでPermitFileReading[]があるときにダメか。ワークアラウンドとしてこの行をコメントアウトというのも危険ですかね。PermitFileReadingはzfile.cの中。追跡中…。

gs-esp 8で入ったzfile.c:check_file_permissions_reducedの中での処理がどうもおかしい気がする。

む、わかったぞ。(というかもっと早く気付けこのアホウな自分、という感じだけど。)

まず、gs-espでSAFER(.setsafe)を付けると、GSパス(gs -hで参照できる)および環境変数GS_LIBのファイルのみを信頼する。TTF/TTCフォントを使うために、defomaパスの/var/lib/defoma/gs.d/dirs/fontsをデフォルトパスに加えてはあるのだが、実はこれは機能しない。defomaのgs.d設定ではTTF/TTCファイルへのファイルパスを、その中に格納するsymlinkではなく、実体のパス、すなわち/usr/share/fonts/truetype/内ファイルへの参照としている。/usr/share/fonts/truetype/はGSパスに入っていないため、許可対象にならず、エラーとなる。

ワークアラウンドな対策としては、環境変数GS_LIBに対して、「GS_LIB=/usr/share/fonts」のようにフォント実体を格納するパスを加えればよい。

ただ、これはgs-espが悪いんじゃなくて実体フォントを返すdefomaが悪いと思われるので(フォントの全パスをgs側で指定してたらdefomaの意味がない)、symlinkファイルをsafeコードが許してくれるようなら、defomaのgsコードを直すのが適切だろう。

ということで本日のハックは時間切れ。

リンク [hatena] | Debian