ただのにっき

■ オライリーのebookから余白を除去して、Kindleで快適に読む方法

オライリーの被災者支援キャンペーンは大盛況のうちに終わったようで、最大で百数時間待ちになったようだ。おれが注文した3冊も昨晩遅くにようやく届いた。「同時にKindleを買うとどっちが先に届くだろう」なんて冗談を言い合っていたけれど、これはマジでKindleの方が早かったかも知れない。

それはさておき、買ったからにはちゃんと読みましょう(Kindleで)。ただし、紙の書籍をレイアウトそのままでPDFにしたものは、はっきりいって電子書籍端末では満足に読めないと思ったほうが良い。特にKindleをはじめ5～6インチの画面を持つ端末ではPDFの余白が極めて邪魔くさい。というわけで、これを除去してから読みたいものだ。

下のスクリーンショットはオライリーの「セキュリティの神話」を横向きにした表示したところ。上は買ったままのPDF、下は余白を削除することで文字の表示サイズを大きくしたもの。読みやすさは一目瞭然だ。

上のサンプルは幅15cmの書籍なので、余白を除去すれば(老眼に苛まれていない人は)縦持ちでも読めると思う。ただ、これが18cmの大型本になるとどういうことになるか、想像するまでもないだろう。というわけで、5～6インチ端末で書籍のPDFを読むにはこの余白除去加工が必須になる。

電子書籍端末向けにPDFを加工するには、テキストデータを抽出する方法や、PDFをそのまま加工(crop)する方法があるが、オライリーのPDFはDRMがかかっているのでいずれもうまくいかないようだ。ここは紙の書籍と同じ「自炊」の手法を使って加工することにする。画像化するのでファイルサイズは数倍に膨れ上がるが、あとからOCRをかければテキスト情報も扱えるようになる。

で、おれが自分で自炊するためにちまちまと整備してきた「自炊用Rakefile」がオライリーebookにもそのまま使える。Linux(たぶん他の*NIX OSでもOK)が必要だが、まぁオライリーで技術書を買うような人は自由になるLinux Boxのひとつやふたつは持ってるでしょ。

注意: このスクリプトは非常にCPUを食うので、電力事情の悪い関東地方の人は日中に走らせるのはやめよう。電力が逼迫していない夜間、寝てるあいだにブン回しておけばよろしい。

使い方はだいたい以下のとおり:

1. 関連ツールをインストールする。rakeは当然だが、ヘッダに書いてあるパッケージが必要(Debianの場合。Ubuntuでもたぶん同じ)。
2. PDFファイルと同じディレクトリにRakefileをコピー
3. Rakefileの「SRC」の値をPDFのファイル名に書き換え
4. rakeコマンドを実行

しばーらく待つと、カレントディレクトリに「元ファイル名.out.pdf」というファイルができているはず。ただし、指定したパラメタではきれいに余白が除去できていないかも知れないので、場合によっては下記の方針でRakefile中のパラメタをいじる必要がある。

• 余白が残っている、または文字が切れてしまっている : TOP / BOTTOM / LEFT / RIGHTの数値を加減する。厳密である必要はなく、余白の自動認識のノイズになる部分さえカットできれば良い。pgmディレクトリに展開された元イメージの持つ余白のピクセル数を測ることでこの数値を見極められる。
• 色が薄すぎる : カラーページの多い書籍の場合、文字の色が薄くなってしまう場合がある。通常はKindle側の設定でコントラストを高めれば十分だが、事前に濃いめにすることも可能。LEVELパラメタ(デフォルトで「0%,100%」)を「0%,100%,0.5」のように変えてみよう(末尾に足した数値はガンマ補正で0.0～1.0。小さいほど濃くなる。詳しくはImageMagicのマニュアル参照)。
• 縦持ち向けにしたい、または他の端末向けに加工したい : 現在配布しているサイズ指定(SIZEの値)はKindleの横持ち表示の幅である「720」つまり幅720ピクセル(最終的な仕上がりは722ピクセル)になっている。「自分は目がいいから縦持ちでOK」とか「SONY ReaderやGALAPAGOSで読みたい」という場合にはSIZEの値を変更する。Kindle縦持ちの場合は「x735」(縦735ピクセル)に変更する。他の端末の場合は最適なサイズを自分で決めてね。

それでは、快適なKindleライフを!

■ 「オライリーのebookから空白を除去……」に関する補遺 : 主にメタ情報に関する追記

オライリーのDRMについて批判的なことを書いたらyomoyomoさんから容赦ないとか言われてしまったけど(笑)、実はおれもオライリーの編集さんと話をして、現在の状況がオライリー・ジャパンの(主に流通面での)特殊な立ち位置に由来することくらいは知ってはいるのである。

ただ、先の記事が事実上DRMを迂回する方法にもなっている、つまり、余白やノンブルだけでなく、せっかく膨大なCPU時間と貴重な電力をかけて埋め込まれた所有者のメールアドレスすらも削ってしまう上に、こうして生成された画像化PDFを再度OCRにかければテキストデータを取り出すこともできてしまう*1ことからして、IT技術者の手にかかればこの程度のDRMが無意味なことは明らかなのだ。しかもこの加工をするために今回新たにebookを購入した電子書籍端末のユーザが、各地でこのスクリプトを実行してさらに電力を消費するのだ。最初から(本家オライリーのように)PDFだけでなくEPUBやmobiでも公開しておけば回避できた浪費である。このご時世に(←伝家の宝刀「このご時世」)。

ということを(業界のしがらみなど知ったことではない)ユーザの立場からちゃんと指摘しないとダメでしょう、と思うのであえて空気を読まないんですよ、ワタシは。

それはさておき、オライリー・ジャパンのebookにはDRM以外にも重大な欠点があって、困ったことにメタ情報が設定されていない。PDFにはちゃんと書名や著者情報をメタ情報として設定できるのに、ebookのメタ情報は空っぽである。しかも編集不能なので、あとから自分のためにメタ情報を追加することもできない。

先のスクリプトでは最初のタスクでmetadata.txtというファイルが生成されて、これは元PDFのメタ情報を抽出し、あとから生成されたPDFに同じものを設定するためのものなのだが、ebookの場合ここには味気ないIDとページ数くらいしか入っていない。

もしメタ情報をちゃんと指定したいのであれば、手持ちのPDFから同様にmetadata.txtを抽出しておいて、それを編集してから再度rakeコマンドを実行すれば反映できる*2。Kindleの場合、書名はPDFのファイル名から採用されるが、著者名はメタ情報から取られるので(ただし英語のみ)、設定しておくと書名リストで表示される情報が増す。

もっとも著者名だけなら別にあとからAdobe Readerからでも設定できるからこんな手の込んだ方法をとらなくても良いのだが、ここでScanSnapで生成されたPDFから抽出したメタ情報を元ネタに使うとScanSnapユーザには別のメリットが生まれる。ScanSnapが生成したPDFにはgeneratorとしてScanSnapに関する情報が指定されているので、これを使い回すことでScanSnap付属のユーティリティでOCRをかけることができるようになるのだ(このツールはScanSnap由来のPDFでないとOCR処理を拒否するのである)。

という豆知識でした。