ただのにっき

■ 自炊PDF制作をrake化してみた(途中)

目的と手段が入れ替わってる自炊本シリーズ第N段。

自炊本制作はこないだベストプラクティスとか書いた以上、セッティングはだいたい詰められたんだけど、まだ作業が最適化されてないのが気に食わない。具体的には余白をきれいに除去するためにpdf2kindleを何度も実行してパラメタを詰めるところね。PGM→PNG化の処理を繰り返すために、スクリプトの特定の関数だけを実行したいわけだ。

そのためにいちいちスクリプトをいじるのはアホらしいし、そもそも複数の工程が含まれているんだからここはRakeの出番だろ。というわけでRake化してみているのだが、白状すると自分でRakefile書くの始めてなんだよな、今ごろ何言ってんだという話だけど*1。まぁ、いい練習台を見つけたということで。

で、それっぽく動くようなものはできたものの、依存関係がまだうまく解決できないんだよなぁ。ソースが1個しかないけど、途中の生成物が複数できる(しかも個数未定)場合のうまい指定方法がわからん。

Kindle最適化PDF生成の工程がどうなってるかというと、こんな感じ:

1. ScanSnapでスキャンしたPDFから、1ページ単位の画像(pgmフォーマット)を切り出す。スクリプト実行前には何個のpgmファイルができるかわからない。
2. pgmファイルから余白を削除したpngファイルを作る。ここは1対1の関係なのでまさにRakeの面目躍如。ちなみに何度も実行してチューニングしたいのはこの工程。
3. 元PDFのメタデータを別途抽出する。
4. pngファイル群を結合し、メタデータを設定して、最終的なPDFファイルを生成する。

問題は途中の工程で生成される画像ファイルの数がわからないことで、ファイルリストが作れない。結果として最初のタスクの依存関係がうまく書けない。たぶんRakeマスターなら知ってるうまい技があると思うんだけどなー。

なお、工程1をやめて、最初から(PDFではなく)画像としてスキャンするというソリューションもあるにはある。これは最終手段。

■ 自炊画像を使ってmobiファイルを作ってみた

なんとなしにmobiファイル(Kindle特有の電子書籍フォーマット)の作り方を探っていたら(参考にしたのは「電子書籍の作り方 (Kindlegen)」とか)、なんだかずいぶん簡単なことがわかった。ようするにHTMLにメタ情報を与えるだけじゃないか。ePUBと同じなんだな。てことは、画像を埋め込んだHTMLを作れば、自炊本もmobiにできるってことか。

ということで、ちょっと作ってみたのだ。pdf2kindleで余白をカットしたPNGを生成してあるので、それらすべてをimgタグに挿入したHTMLを生成。上のリンクを参考に、画像ごとに改ページを示す特殊のタグを挿し込んでやれば、1画像1ページになる。メタ情報opfファイルも作成して、Linux用kindlegenに食わせたら、けっこうあっさりできた。サイズはPDFとさほど変わらない(少し大きいかも)。ImageMagicでPDFを生成するのに比べると、1/100くらいの時間でできた。作るという観点だけから言えば、こっちがいいなぁ。

で、さっそくKindle3に読ませてみたわけだが、結論から言うとダメだこりゃ(笑)。

まず、上の方に妙な余白がある。上のスクリーンショットを見ればわかるが(左がPDF、右がmobi)、なぜか純正フォーマットであるはずのmobiの方が表示面積が狭い。たとえ文庫本でもできるだけ大きな字で読みたいので、これは良くないなぁ。まぁ、画像だけからなるファイルは想定外なんだろうけど*1

あと、PDF表示ではできるコントラスト調節がmobi表示ではできない。それから、Kindleを横持ちにしたときに表示が「Fit to width」相当にならない!(Fit to heightのみ) これはつまり、縦長の画像からなるページは小さく縮小されて端に寄せて表示されるだけ、拡大されない。mobi表示は本当にちゃんとテキストからなる専用書籍のための機能なんだなぁ。

というわけで、自炊本のためにはPDFが最適だということを確認したにすぎないのであった。まぁ、TEXTやHTMLで長いテキストを入手した時には自分でmobiが作れるようになっておくのはいいことなので、それはそれでいいのだけど。でもまぁ、メモリが潤沢なPDF生成環境は欲しいやねぇ。そのためにVPSを一個借りるか(ぇ

■ 電子書籍で生き残る技術−紙との差、規格の差を乗り越える−(川崎 堅二)

いやー、思った以上にアグレッシブな本だった。

前半は「電子書籍の歴史をおさらい」みたいな感じで、まぁ、この業界に少しでも興味があればだいたい知ってる話がうまくまとめられていて、「まぁこんなもんかな」と思いながら読み進めていたら、後半はうってかわってぐっと「技術寄り」の話になる。それも電子リーダーとか配信に関する技術話ではなくて、1ソース・マルチユースな書籍を作るためのソフトウェア的な技術の話である。

で、本書に登場するのがおなじみ@kmutoや@takahashimで、出てくる用語も「ReVIEW」とか「GitHub」なわけで、たぶん紙の出版社の人が読んでもほとんどチンプンカンプンなんじゃなかろうか。ただし、ここに書かれているような「著者にも扱える中間フォーマット」とか「著者にもバージョン管理システムを使わせる」なんて話は動きが速くて先行き不透明な現在の電子書籍業界で「生き残る」(まさに本書のテーマはこれ)ためには必須の話だ。だから、Pragmatic Bookshelfや達人出版会の例を持ち出すまでもなく「本好きの技術者」がやる出版社には未来があると思う*1。

そんなわけで、ちょっと毛色が違うけれど、ちゃんと現実的な未来を見すえた「電子書籍に関する書籍」としてかなりいいセンいってると思う。噂によれば著者はオーム社にの中の人らしいので、自前でeStoreを運営したりする*2のはそういう思想の現れなのかも知れない。

ちなみにおれは本書をeStoreで購入してPDFで読んだわけだけど、紙と同じデザインの紙面なので、当然ながらKindle3では読めなかった。わざわざ画像化して余白を削除したももの、それでも相当字は小さかった。やたらと面積と取っている脚注部分だけカットすればずいぶん読みやすくなったのだけど、コラムやインタビューにはその余白すらないし。

本書でさんざん述べられているように単一のソースから複数のフォーマットが生成できるのがこれからの電子書籍なのであれば、eStoreでもPDFだけでなくePUBやmobiでもダウンロードできるようにして欲しかった*3。少なくとも紙とまったく同じレイアウトで出すというのは、ちょっと工夫がなさすぎるんじゃないの、と思う。

なお、Amazonから(紙バージョンを)買うなら上の書影をクリック。電子版をオーム社から直接購入するなら下記から:

Ohmsha eBook Store is no longer available.