Popplerについてちょっとだけ
今日は酔っ払ってはいませんので通常営業に戻りますが、ちょっと仮眠のつもりが爆睡してしまったので、まあ、えと、日記にするにはあまり時間がないです。
とはいえPopplerについてはぼくそれほど詳しくないので、一瞬で終わると思います。
Poppler とは？
FLOSS の PDF 操作ライブラリの一つで、総合的に見て一番使いやすいものです。総合的にというのは、依存関係が小さいとか、性能面とか、コミュニティの活発さとかそういう面を含めて、と認識してます。
開発主幹は Free Desktop の Poppler プロジェクトで、OpenPrinting が upstream になっている cups-filters とかはコイツをまあまあ使っています。
厳密にいえばプロジェクトとしては poppler-utils*1 というユーティリティも含んでるんですけどね。
Poppler の歴史
って、そんなに知ってるわけじゃなゆるくてごめんいです。すんません。
- 元は XPDF という、名前からもろわかりな用に X で PDF を表示するソフトウェアから描画ライブラリを切り出したもの
- 元が表示アプリなので描画ライブラリとしてはそこそこだったが、操作系とかはちょっと弱かった
- 開発コミュニティは非常にオープンで、外部からのパッチもさくさく受け入れてくれる
- めんどくさい政治的交渉はあんまりいらない
- CJK についても非常に協力的
- 日本人コミッターもいらっしゃいます
- そんなわけで OpenPrinting では PDF 印刷パスのライブラリとして Poppler を利用
- 今は弱いとされていた色管理系と、あと注釈 (annotation) まわりの機能がけっこう活発かな
Linux 印刷 と Poppler
結局 Linux 印刷において、Poppler との付き合いは「PDF 印刷パスをどんぐらいまじめにやるか」なんですよね。
例えば手元の Ubuntu 12.10 においては：
$ cd /usr/lib/cups/filter $ ls *pdf* bannertopdf imagetopdf pdftoijs pdftoopvp pdftopdf pdftops pdftoraster pstopdf texttopdf
てな感じです。それぞれ：
| 名前 | *内容 | |
|---|---|---|
| bannertopdf | バナーファイルから PDF を生成する。印刷の前段で使用。 | |
| imagetopdf | gif, jpeg, tiff, png などから PDF を生成する。印刷の前段で使用。 | |
| pdftoijs | PDF から、ijs というちょっと古めの OpenPrinting のインクジェット用標準 I/F を叩くためのモジュール。ドライバーを作るためのモジュールとして用意。 | |
| pdftoopvp | PDF から、日本の一部のベンダーが利用しているベクター形式ドライバーI/F OPVP を叩くためのモジュール。ドライバーを作るためのモジュールとして用意。 | |
| pdftopdf | PDF を加工してページ面付けその他をする。中間処理用。 | |
| pdftops | PDF から Postscript プリンター向けに PS を生成する*2。 | |
| pdftoraster | PDF から cups raster を作る。プリンターベンダーは cups raster を読み込んで各自のデータ形式に変換できる。 | |
| pstopdf | CUPS キューへの入力が PS だったときに PDF にするフィルター。 | |
| texttopdf | CUPS キューへの入力がテキストだったときに PDF にするフィルター。悲しいかな日本語は通りません。 |
ということなのですが、ldd して poppler 使ってる奴見ると、あれあれ、
- pdftoraster
- pdftoijs
- pdftopovp
- bannertops
と随分減っちゃいました。
入力フィルター系はけっこう使ってますね。これはまあ、描画は得意なんで当然です。
pdftopdf が使ってないのは、Poppler は操作系が弱いのでページ面付けとかそっち方面はあまり達者じゃないということです。実のところ、「Poppler としても操作系が充実することはいいことなんだから(例えば Evince で高度な面付けができるようになったりする)、Poppler コミュニティと連携取ってちゃんとやったほうがいいんじゃね？」って議論があったと記憶してるんですが、結局枝分かれするという安直な (失敬) 道を選んじゃいましたねえ。少し残念なんですが、この知見をフィードバックするとかいう議論がまたできればいいな、と。
悲しいのは pstopdf で、これ実態はシェルスクリプトなんですよね。先頭の数行見るとわかるんですが：
#!/bin/sh # $Id: pstopdf,v 1.3 2003/02/15 15:21:00 gurubert Exp $ # # This is a Postscript to PDF filter for CUPS # # (C) 2003 Robert Sander <robert.sander@epigenomics.com> # (C) 2008-2012 Till Kamppeter <till.kamppeter@gmail.com> # # Released under GPL # # NO WARRANTY AT ALL # set -e PS2PS=`which ps2ps` GS=`which gs` ...
内部でおもいっきし GS 呼んでおります…… orz
これがこないだちょっと書いた「PDF 印刷パスな人に PS アプリがデータ投げると一旦 GS 通ってパフォーマンス・品質共に劣化する」の意味です。はあ。
pdftops は、PDF と PS は論理構造が似ているので手で生成してるんだっけ。ただこれも /usr/share/cups/mime/*.convs 眺めると、使われないフィルターパイプラインはちょこちょこあるような……。ちゃんと経路計算してないから、わかんないですけど。
pdftoijs と pdftopvp は使ってるんですが、前者は今使ってるベンダーどんだけいるのかしら？ という話だし、pdfopvp については皆無です*3 おかげで「ねえホントにいるのこれ？」って upstream から言われちゃったりしてかわいそう。
あと、PDF 印刷パスの初期の実装は Poppler の I/F だけ借りて内部は全然別のことをやるというフィルターがいくつかありました。pdftopdf なんかそうでしたかね。これは操作系が弱い Poppler を手直しすることを避けて、なおかつ使えるところは使おうという意味で悪い判断じゃなかったと思うんですが、CUPS 1.6 で CUPS が PS 関係のフィルターを同梱しなくなって、 cups-filters を各ディストリビューションが使わざるを得なくなったときに Red Hat がソースコードを調査して、「これって fork だけど、Poppler 側でセキュリティ問題起きたときに追随できる体制あんの？」と突っ込まれて、いや、I/F 借りてるだけなんだから内部の処理は大きく違うし、I/F だけなら問題なくね？ って話をしたんだけど通らなくて、結局フルスクラッチで書き直すという結論になったとか言うのはあります。
あんまりまとまってないまとめ
Poppler コミュニティのオープンさというのは ML 見てるだけでも感じるしそこはすごい好感をもちます。
一方で操作系が弱いのはちょっとテコ入れしたほうがいいんじゃないかと思ってて、だってさっきも書いたけど Poppler の操作系、つまり PDF のページ入れ替えたり、面付けしたり、そういう作業ね、それが充実したら、Evince が Adobe Reader 並の機能を持てる可能性があるってことっすよ。週刊誌綴じとか Evince でできたらうれしくないすか？
だから今回は短期的な開発スピードを優先して pdftopdf を一から書くという決定になったわけですが、ここはちゃんとコミュニティ同士でうまく話し合って、最終的には Poppler の方に入れ込んでいくようなことになればいいなーと思います。
あと、Poppler でできそうなんだけどなぜか GS 使ってる的な部分が、PDF 印刷パスの初期にはすごくいっぱいあったんですけど、今久しぶりに見たらだいぶん改善してるのかなという印象を持ちました。さっきもいいましたけど、CUPS の場合はフィルタパイプラインをコストによって動的に計算するので、そこちゃんと調べないとなんともいえないですけど、昔は「中見ると gs 読んでる」がもっといっぱいあった気がしたので。これは Poppler が品質面でちょっと問題があったのと、カラーマッチングについては GS のレベルにぜんぜん達してなかったというのはあるんですが、もしそれが改善されているというコトなら嬉しいですね。
ということで、頑張れ Poppler！
Red Hat 系が使うようになったので品質についてはかなりブーストがかかるんじゃないかと予想してるので、今後が楽しみだ！
これからの Poppler 先生の活躍にご期待ください。
*1:もしみなさんが Debian 系のユーザーなら apt-cache show poppler-utils とやってみるといいです。
*2:PS Level3 のプリンターなら PDF 直接印刷できるから変換不要なんじゃねーかと思うんですが、ジョブ情報の適切な標準がないとかそういう理由なのかなあ。PDF は印刷フォーマットではなくあくまでも構造化文書なのでジョブ情報とかの持ちようがないんですね。んで PDF 直接印刷のときには各プリンターベンダー固有の方法でジョブ情報を渡すんだけどそこが標準化されてないから、ということかなあ。
*3:Ghostscript から切り替えてこっち使うためにはベンダーの判断が必要なんだけど、どっちも「現状問題起きてないからリスク負いたくない」って気持ちはあるんじゃないかな。想像。
