ただのにっき

■ グスタフ、主治医にトラウマを残す

ガソリンはめちゃめちゃ高いし、まだ余震もおさまってないものだからあまり遠出をする気にもならず、ここしばらくは週末は自宅でまったり過ごすことが多い。必然的に猫たちを観察する機会も増えるのだけど、グスタフとドーラは(おそらく)同じ親から産まれたとは思えないくらい性格が違う。今日もけっこう大きい地震があったのだけど、寝ていたグスタフはすぐに起き上がってキョドキョドとあたりを見回しているのに対し、ドーラは何ごともなかったかのように寝続けていた。度胸座ってるよなぁ、ドーラは。体重が倍も違うとはとても思えんグスタフの腰抜けっぷり。

そういえばドーラの発情期、何度かぶり返しつつもそろそろ終息した気配なので、このタイミングで不妊手術をしておこうと思い、予約を入れに獣医へ行った。

市の助成金申請をしないといけないということがわかったので(←カンペキに忘れていた)、申請が通るまで手術はできないから予約できず、というオチ。まぁ10日もすれば通るらしいので4月中にはできるだろう。

それよりも、実際に病院に預けにくる段になったらという話の流れで、何かに怯えたような目をした獣医師が「暴れるといけないから袋かなにかに入れてきて下さい」と言うのだよ。センセイ、こいつはドーラで、グスタフじゃありません。というかグスタフはすでに去勢済みですって。

どうもおれのことを「ものすごく暴れる危険な猫の飼い主」と認識しているらしい。ベテランと一言でいうのも申しわけないくらい年季を積んだ獣医師に、ここまで恐れられるグスタフって……。しかも、強くて乱暴なんじゃなくて、めっちゃ弱虫ゆえに暴れてるだけというのがまた情けないったら。

写真は、届いたばかりのAmazon箱をあけたら、中身を取り出す暇もなく飛び込んできてドヤ顔をするグスタフ。愛嬌だけは抜群。

■ 「オライリーのebookから空白を除去……」に関する補遺(2) : バイナリパッチによる空白の除去

先日のPDFの空白除去の話にはいくつか興味深い反応があって、(あえてリンクはしないけど)DRMそのものを外してしまう方法がまずあった。実はそれは以前から知っていて、いくつかのPDFビューア(特にオープンソースのもの)ではそもそもDRMを無視してファイルを開くし、その他にもDRM破りのツールはいくつもある。DRMさえ外せれば、たとえばPDF Scissorsなどを使えばインタラクティブに空白を除去できる。興味があれば調べてみるといいだろう。

ただ、自分はDRM破りは最後の手段だと考えているので、他に手があるうちはそっちを選ぶ。DRM破りはいつか違法になるかも知れないし(もうなってるんだっけ?)、それよりも最初からDRMのかかっていない品物が入手できる世の中になるように活動した方がいいと思う*1。ま、このへんは人それぞれで。

一方、面白い手法の紹介もあった。わいえむねっと - 2011/03/30で紹介されているのは、PDFファイルの「CropBox」指定を直接書き換える方法。バイナリパッチだ! これはいいな(笑)。Perlだと何やってるのかすぐに理解できなかったので、ロジックそのままにRuby(もちろん1.9)で書きなおした(写経?):

# left, bottom, right, top
OFFSET = [47, 45, -47, -62]

print( ARGF.read.force_encoding( 'ASCII-8BIT' ).gsub( %r|(/CropBox\s*\[\s*([^\[]+?)\])| ) do
   orig, box = $1, $2
   offset = OFFSET.dup
   crop = "/CropBox[#{box.split( /\s+/ ).map{|s| s.to_i + offset.shift}.join(' ')}]"
   blank = orig.length - crop.length
   blank > 0 ? crop + ' ' * blank : orig
end )

「セキュリティの神話」を上記のOFFSET値で処理したのが下のスクリーンショット(ちょっと字が薄かったので、Kindle上でコントラストをもっとも濃くした状態):

奇数ページと偶数ページでちょっと余白の大きさが違うので、あまりキツキツにはできないけど、まぁこれで十分かもしんない。ファイルサイズも数分の一になるし。余白の自動認識をしているわけではないので設定は何度か試しながらツメないといけないけど、処理が一瞬なので苦にならないね。オライリーのebookは今後はこっちで処理しようかな……あー、いや、メタ情報の問題が残ってるか。ううむ。

■ オライリーの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処理を拒否するのである)。

という豆知識でした。