読者です 読者をやめる 読者になる 読者になる

おがさわらなるひこのオープンソースとかプログラミングとか印刷技術とか

おがさわらなるひこ @naru0ga が技術系で興味を持ったりなんだりしたことをたまーに書くブログです。最近はてなダイアリー放置しすぎて記事書くたびにはてな記法忘れるのではてなブログに移行しました。

クリエイティブ・コモンズ・ライセンス
特に断りがない場合は、本ブログの筆者によるコンテンツは クリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスの下に提供されています。

PDF印刷パスがびみょいのはなぜ?

今日は入門編。ほかのことやってたら遅くなっちゃったので、病み上がりの身としては早く寝ないといけないので。


PDF 印刷パスというのは昨日のエントリーに書いた、「印刷中間データ形式」を PS ではなく PDF にしようという試みです。これはメリットがあるから当然そうやっているわけですが、過渡期なのでいろいろ悲しくなってます。その問題をちょっと概観しましょう。

本当は Ghostscript (通称 GS) とか Poppler の話を先にすべきなんですが、今日は無理。明日書きます。

アプリは PS で出し、CUPS 側は PDF 印刷パスを採用している場合

  • 中間データ形式は PDF なので PS -> PDF -> PDF -> 最終的な印刷形式、にしないとダメ
  • PS から PDF に処理できるマトモなソフトといえば GS しかない
  • PDF から最終的な印刷形式にするにはやっぱり GS しかない
    • 本当は印刷形式によっては PDF 操作ライブラリ Poppler を使う手もあるんだけど、Poppler はまだカラーマッチングとかそこらへんの機能が弱いので (だいぶ改善されてきたけど)、結局のところ使ってない
  • ということは PS 印刷パスなら PS -> PS -> 最終的な印刷形式、だったので GS を呼ぶ工程が一回増えてしまう
  • もしプリンターが PS だった場合は PS -> PDF -> PDF -> PS となるのだが、これも GS を二回呼ばないといけない。PS 印刷パスなら GS を一度も呼ぶことなく印刷データが生成できるのに!
    • 本来なら PostScript Level3 をサポートしているプリンター = PDF を処理可能、なので、PDF のまま投げればいいのだけど、今のところそのパスは潰されている (詳しくは別途)
  • しかも、多分だけど GS 自身が吐いた PDF を処理するのを GS はあまり得意としてないらしくて、メモリ食いまくって死んだりすることもある

アプリは PDF で出し、CUPS 側は PS 印刷パスを採用している場合

  • この場合は PDF -> PS -> PS -> 最終的な印刷形式
  • プリンターが PS プリンターの場合は GS 一回呼ばれるだけだからまだマシ
  • そうじゃない場合は上のパターンと大体同じ
  • PS プリンター持っててFedoraSUSE で印刷おかしいなーとおもったら、アプリに設定があるなら PDF じゃなくて PS に切り替えるという手がある

アプリは PDF で出し、CUPS 側は PDF 印刷パスを利用している場合

  • この場合は PDF -> PDF -> 最終的な印刷形式、だからうれしいはず
  • でもやっぱり遅い気がする
  • 想像だけど GS の PDF ハンドリングはあまり練られていないんじゃなかろうか
    • GS すてて Poppler 使えればこっちの水はよくなると思うんだけどなー
    • ついでに PDF ダイレクト印刷の経路も作るともっとよくなると思うんだけどなー


説明足りないからナンノコッチャ? と思うかもしれないけど、もう寝なきゃなので許して。