PDF印刷パスがびみょいのはなぜ？ - おがさわらなるひこのオープンソースとかプログラミングとか印刷技術とか

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

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

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

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

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

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