トップ «前日 最新 翌日» 編集
RSS feed

ただのにっき


2011-01-07(金) [長年日記]

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

Tags: ebook kindle
本日のツッコミ(全6件) [ツッコミを入れる]
sasasin (2011-01-08(土) 02:23)

pdftoppmはノーマークでした。150dpiがデフォとは。画期的だし嬉しいのですが、画質面はこれで開拓しつくしちゃった感がちょっと寂しいです。

ただただし (2011-01-08(土) 05:26)

わからなくもないですw > 寂しい

imudak (2011-01-22(土) 00:36)

最近Kindleを手に入れて、自炊本を読むのに重宝しています。ありがとうございます。
自分の自炊ファイルではちょっと問題があったので、gistからforkさせてもらい独自に対応しました。
rakeはおろかrubyも初めてで、やっつけ仕事になってますが…

https://gist.github.com/788127

対応したのは主に以下の点です。
・白紙のページのconvertでエラーとなったpngのPage Generationがとんでもない値になり、Kindleでみると
 数ページに渡り白紙になってしまう問題に対応。
・100ページ以下のPDFに対応。
・環境変数でPDFファイルを指定するようにした。
・同じく環境変数指定で、本の種類ごとにテンプレートパラメータを選べるようにした(値は適当)。

以上ご参考になれば幸いです。

ただただし (2011-01-22(土) 01:01)

ありがとうございます、拝見しました。私はスキャンの時点で白紙を飛ばしているので、そういうメにはあってないんですねw

SRCのファイル名の自動設定はいいアイデアだと思いました、いただきます。ただ、環境変数含め、外部から情報を与えるのはあえて避けているんですよ。時間があくと、以前どんな条件で実行したのか忘れてしまうので。今の仕様なら、Rakefileさえ保存しておけば前回の状況を再現できます。

imudak (2011-01-22(土) 02:17)

白紙飛ばすと印刷のページ番号とずれちゃってどうにも気持ち悪かったのでそのままにしてたんですが、思わぬ落とし穴でした…

環境変数方式にしたのは、複数ファイルを一気に変換するための苦肉の策です。
Rakefile内で閉じたかったんですが力不足で、ついついrakeを外から呼び出すbashのスクリプトを書いてしまいました。

元の仕様の方が、変換途中のデータもそのまま残せるし賢いですね…

ただただし (2011-01-22(土) 05:54)

まぁこの世界、古くからmkmfのようなプログラムが存在するわけで(今ならAutoconf?)、アプローチとしては間違ってないと思いますよ~


トップ «前日 最新 翌日» 編集
RSS feed