ただのにっき

■ Kindle3向けdot by dotな自炊PDFを(真面目に)作成する

ePUB 3.0が、縦書きやルビをサポートしてそろそろ仕様確定するそうで、それはそれでめでたいんだけど、各種デバイスがいつサポートするのかもわからんし、出版サイドにノウハウがつくのにも時間がいるだろうし、普及にはしばらくかかるだろう。

いっぽう、大長編「まおゆう」を自作したPDFで読んだり、最近高橋さんが作っているSONY Reader向けの青空文庫PDFをKindleに入れてみた経験からすると、電子書籍は必ずしもリフローできるフォーマットである必要はないんじゃないかとも思い始めている。世に出回っている電子書籍端末は、3～4インチ(スマートフォン)、5～6インチ(KindleやSONY Reader)、10インチ前後(いわゆるタブレット)の3種類。だったらこれらに合わせて最低3種類のPDFを選択可能にしてくれればそれで十分じゃないのか? 字の大きさのバリエーションを2種類作ってもせいぜい6種類。これで大多数の人が使えるなら、ePUBじゃなくてもいいわな。

いずれにせよ、現時点でePUBが読めないKindleがePUB 3.0をサポートするかというと怪しいと思うので、自分にとって自炊本がソースである期間はまだしばらく続きそうだ。

というわけでベストプラクティス宣言後も、シェルスクリプトのRakefile化と並行してチマチマと最適化をしていたりして。なにせ、字がまだ汚いのだ。ちなみに最新のRakefileはGitHubで公開してある。

最近の発見(?)は、pdftoppmが吐き出す画像ファイルのデフォルトの解像度が150dpiだったこと。えーと、たしかおれ、600dpiでスキャンしてたよね? 150dpiつったら、Kindleそのものの解像度より小さいわけで、そんな画像を拡大表示してたら汚くてあたりまえだ……。というわけで「-r 300」をつけて大きめの画像を抽出するようにした(「-r 600」ならなお良いが、300でも十分な解像度である)。

それから、これをトリミングしたあとで、Kindleの画面にぴったりフィットするようにあらかじめリサイズする。けっきょくこれが一番確実なのがわかった。そのために、真っ黒な画像を使ったPDFを作り、Kindle上でどれくらいの大きさに表示されるのかチェック(ググればわかるように他の人も似たようなことをしているけど、みんな微妙に数字が違うので自分だけを信じることにした[笑])。

まず文庫や新書向けの縦持ち(ポートレイト)の場合、560x735がPDFの表示エリア。紙の書籍を画像化した場合は縦がつっかえるので、高さ735に最適化すれば良い。ImageMagicには「-resize x735」を指定する。できたPDFのスクリーンショットがこんな感じ。ちょっとノイズが乗っているけど、実際にKindle上で読んでいれば気づかない程度:

続いて大型の技術書を横持ち(ランドスケープ)で読む場合、722x535が表示エリア。こんどは横だけフィットすれば良いので、ImageMagicのオプション指定は「-resize 722」になる。これで最適化するとこんな感じ:

これならmobiな書籍と比べても遜色の無い美しさだよ。満足だ。長かったけどこれで最適化の旅はたぶんおしまい。あとはファイルサイズ削減のためにもうちょっと圧縮率を上げられないかトライするかも。