2010-12-05(日) [長年日記]
■ Kindle3向け自炊本作成手順、(おれ的)ベストプラクティス
注意: この記事は古くなっており、現時点ではベストでもなんでもなくなっている。進化した「Kindlize手法」についてはKindle3向けdot by dotな自炊PDFを(真面目に)作成するを参照されたい。
あれこれ試行錯誤の末、自分的にだいたい納得できるクオリティの自炊本作成手順ができたのでメモっておく。対象はKindle3。
例えばiPadをはじめとする大型タブレットだとこういう苦労はあまりなくて、気にせずフルカラーかグレースケールでスキャンしてPDFにしてしまえば難なく読めるんだろうけど、Kindle3やSONYのアレみたいなモノクロの5～6インチ画面向けにはいろいろ最適化が必要だ。だからKindleダメというわけじゃなくて、この軽さ、小ささ、そしてE-Inkの美しさを享受するためにちょっとした手順が増えることは厭わない、という話だ。
1. スキャン
自炊派の人たちの間では、この時点で各自のポリシーが違ってくるようだ。保存用にフルカラーで取る人もいるが、それだと古めの黄ばんだ本だと地に色がついてしまって、せっかくのE-Inkの白さが失われてしまう。ので、ここは(どうしてもという場合を除き)「白黒」で。
その他、ScanSnapの設定の主なところは以下のとおり。
- 読み取りモード: スーパーファイン、白黒、両面、文字くっきり、白紙削除、傾き自動補正
- ファイル形式: PDF、テキスト認識「しない」*1
- 原稿: サイズ自動検出
2. トリミング
これはsasasinさんのpdf2mobi.shを使うが、彼の元PDFはフルカラーなので、やはり色々と設定が違う。ので、自分用にパラメタを変更してgistに置いておいた(pdf2kindle現在はRakefile化されてさらに進化している)。GPLバンザイ。方向性としては、
- 画像のリサイズをいっさいしない(かえってサイズが大きくなるので。結果的に第二パラメタをなくした)
- PPM(フルカラー)ではなくPGM(グレースケール)を使用
- 文字くっきり化(ガンマ補正)をやめた(代わりにKindleの機能を使う)
- PDFメタデータを最初に抽出
最後のメタデータだが、Kindle上で本のタイトルはファイル名から取られるけど著者名がPDFのAuthorから取られているので(しかも困ったことに日本語はダメ)、ここで入れておきたい。元のPDFに入れておけばいいじゃんという話なんだが、pdftoppmにはうまく取り出せないパターンがあるようなので、pdf2kindleがせっせと画像変換をしている間に、抽出したメタデータファイルをエディタで書き換えられるようにした。
実行時にはノンブルまで削除するためにトリミングのパラメタも指定する。今のところ文庫メインでやっているけど、ハヤカワ文庫だと「60 30 10 10」、創元文庫だと「35 85 15 15」あたりがちょうどいいみたい。
出来上がりはこんな感じで、こないだのとたいして違わないように見えるけど、実際にKindle上で見るとだいぶすっきりして「いかにもスキャンしました」的な感じがだいぶ薄れている。
![[スクリーンショット]pdf2kindleによるPDF](http://userimages.tdiary.net/sho/20101205_0.jpg "[スクリーンショット]pdf2kindleによるPDF")
3. OCR
できたPDFファイルはざっと出来上がりを確認後、ScanSnap付属ユーティリティでOCRにかける。まぁ、小説だったら別にやらなくてもいいかなという感じだけど、CPUの空き時間を見つけてバッチ処理してくれるモードがあるので、寝る前に仕掛けておけば朝にはできたてホカホカの自炊本ができあがっているという具合なので、やっておけばいいと思う。
あとはUSBでつないだKindleに放りこんでおけばいいんだから、たった3ステップ、楽なもんだ。たいして苦にはならないレベルまで自動化できたので満足じゃよ。
*1 これがONだと連続して複数の本をスキャンしにくくなるので後回しにする。
日頃tDiaryでお世話になっているので、いつか何かでお返しができればと思っていました。結果的にご満足いただけたようで安心しました。
いやぁ、いろいろ助かりました。今回一番勉強になったのは、(例によって)ImageMagicの多才っぷりですねー。「-trim -fuzz 80%」はマジですごい!
あとは「スキャンした画像の四隅に点を入れる」（あるいはスキャン画像の一番外にラインを引く）ことで変なセンタリングされなくなります。
すごくためになりました。ありがとうございます。私は以下のような改変をしてみました。測ってないですがちょっと速くなったかも。
* graphicsmagickを使うとちょっと速そう、ということでパッケージさしかえ
* -levelの削除
* -flip -frop で画像回転x2回やるのをやめて2回目の-chop のgeometryに-0-0をつけて右下隅をカットする指定をする
あと松永さん、-trimはまさにその「変なセンタリング」をするための操作だとおもいますよ
>松永さん
四隅にマークを入れるテクは複数のサイトで見かけましたが、スキャン画像のバラつきを考慮に入れるのが面倒なので、気にしないことにしました。たしかにテキストエリアの狭いページがセンタリングされて現れるとちょっとびっくりしますけど、自分はそんなに神経質じゃないので。
＃著名な「No.722」で配布されているツール群はライセンスが妙なのでポリシー的にパスというのもあります。
>moriwakaさん
おお、すばらしい。ぜひパッチを公開して下さい(と言えば公開されるGPL)。たしかに-levelはいらなかったかも。もしかすると元画像がカラー/グレイスケールの場合はここをいじると背景が白くなるのかな……?
でも、一番時間がかかるのは最後のPDF生成なんですよね。あそこを最適化しないと劇的なスピードアップは望めないという(メモリがすごく潤沢なら速いかも知れないけど、ウチのLinuxはVMware上なのでちょっと制約が……)。
「センタリング」の件は、-trimは空白を見つけたら全部ばっさりやる指定なので、文章がページの中で偏っている場合にその部分だけ切り出されてしまって元のレイアウトが再現されないという指摘だと思います。
レイアウトを維持したい場合は -trim じゃなくて -crop にするとよいですね。我が家のLinuxはベアメタル環境で6GBメモリがあるので500ページ越えてもconvert一発で変換できてました。でも速くはないです……。家にもどったらパッチつくりますのでしばしお待ちを。
よく確認すると思ったように動いていなかったのでちょっと時間がかかってしまいました…… パッチはこちら: http://pastebin.com/PdKxZ76n
画像補正のconvertと同じ要領で、PDF作成のconvertを並列化できます。最初のpdftoppmも、pdftkで入力PDFを細切れにすれば、並列化は可能。多コアCPUならこれで速くなります。メモリが潤沢なら、/dev/shmを作業場にしてしまうのもよいでしょう(200MBのPDFを入力に、3GBの中間ファイル、150MBの最適化PDFが出ました)。メモリ容量的に全部が無理なら部分的にでも作業場を/dev/shmにしたり、pngが出来たら不要なppmをちまちま消していく、pdfができたらpngを消していく、とかとか。
ただ、資源制約のきびしい環境では使えない手です。こちらはあまり思い付かないです。。メモリ制限でスワップするなら、今は100ページ単位でPDFを作成していますが、50とか25などもっと細かい単位でやるとか。根本からどうにかするなら、convertやpdftkより速いツールにのりかえるしかなさそうな。。
>moriwaka
ありがとうござます! 参考にします。
>sasasin
まぁ、バッチ処理なので寝ている間に動かせばいいわけで、自分は高速化のモチベーションはそんなに高くないんですけど。
あと、ぱっと思いつくのはクラウド上でサービス化してしまうことですねw PDFをアップロードすると最適化されて戻ってくるという。キンコーズの断裁サービスが成立するなら、最適化PDF作成も有償サービスが成立してもおかしくないとは思います。でも権利的にグレーかなー。コピーがサービス側に残らないことを保証すればいいのかな。
pdf2mobi.shについてまったく使い方が分からないのですが、結構難しい話なのでしょうか？
倉橋さんのスキルやお使いのOSがわからないから、「分からない」だけではなんとも答えようがないですよ。
Linuxユーザの場合→DebianかUbuntuでコマンドライン使い慣れてるなら簡単
Windowsユーザの場合→他のツールを探しましょう(たくさんあります)
MacOSユーザの場合→なにそれ