2010-11-19(金) [長年日記]
■ Kindle使ってみた
自炊した「jQueryクックブック」をKindleに入れて、さっそく持ち出してみた。いやー、軽い。通勤バッグの手にかかる重さが明らかに違う。こんなに軽いとは思ってもみなかったな。この中に何十冊も何百冊も入るんだから、文明の進歩はすごいすなぁ。
で、電車の中で座って読んでいたら、背後の窓から陽の光が差し込んできて、Kindleの画面がさらに美しくなるじゃないの。白い部分はさらに白く、文字はくっきりして、これは紙を超えてるんじゃね? 液晶デバイスだったらシェードを下ろしても厳しそうな光の中で、さらに読みやすくなるんだからもう、これは最高だ。E Ink実にすばらしい。
こういうガジェットって、飲み会で人柱さんたちに触らせてもらったりすることが多いけど、ああいう薄暗いところで他の液晶デバイスと並べてもKindleの良さはわからないんだなぁ。以前ある飲み会でKindle DXを触らせてもらった時もそんなに感銘受けなかったけど、今日は驚いた。こういう新しい表示デバイスをデジタルサイネージみたいな用途でお茶をにごすんじゃなくて、ちゃんとコンシューマ製品にしたてたAmazonはすごいな! Kindleのデモは日中の屋外でやるべき。
……と、手放しで褒めるばかりでも気持ち悪いので、課題も。あ、操作性の悪さはわかってて買ってるので、いちいち書かない。ついつい画面に触れて操作しそうになってしまうのは、スマートフォンで身についた悪癖だ。それ以外では、やはり画面の狭さがネックになる。
「jQueryクックブック」は先日トリミングした結果、それなりに見えるようになったけど、まだまだ字が小さい。
![[スクリーンショット]「jQueryクックブック」の表示](http://userimages.tdiary.net/sho/20101119_0.jpg "[スクリーンショット]「jQueryクックブック」の表示")
PDFは画面にフィットするように設定しても、下にガイドが出たりして、画面いっぱいにはならないということもあり、もうちょっとなんとかして欲しいところ。せめて幅を優先して欲しいので、上端のノンブルあたりもトリミングしてしまおうと考えている。まぁ、横向きにすれば十分な文字の大きさになるので、技術書はそうやって読むことになりそうだ。技術書メインで使うなら(おそらく出るであろう)DX3を待ったほうが良さそう。というか、普通にオライリーやオーム社、そしてもちろん達人出版会から電子書籍を買えばいいのだよ。
続いて、先日他界したJ.P.ホーガンを偲ぶため、本棚の奥から「巨人三部作」を引っ張り出してきて、思い切って裁断した。え? もったいない? 本棚で眠らせておく方がよっぽどもったいない。
![[スクリーンショット]「星を継ぐもの」の1ページ(トリミング前)](http://userimages.tdiary.net/sho/20101119_1.jpg "[スクリーンショット]「星を継ぐもの」の1ページ(トリミング前)")
文庫はKindle 3にジャストフィットするはずだからいいだろうと思ったが、やはり下にガイドが出る分、左右に余りが出る。読めないことはないし、最近の字が大きい文庫なら問題ないかも知れないが、これもざっくりトリミングしてみた。
![[スクリーンショット]「星を継ぐもの」の1ページ(トリミング後)](http://userimages.tdiary.net/sho/20101119_2.jpg "[スクリーンショット]「星を継ぐもの」の1ページ(トリミング後)")
で、こんな感じ。これならなんの問題もない(こっちもノンブル削ってもいいかも)。ということで文庫もかるくトリミングしておくのが良さそうだ。
日本でもブラザーが出してたりするんですけどねぇ，データフォーマットが独自形式とか買うのに躊躇する点が多々ありますけど，何より価格が高すぎるのがね…
http://www.brother.co.jp/product/epaper/index.htm
あ、いや、他にも製品化したところがあるのは知ってますけど(ブラザーという名前はカンペキに失念してましたがw)、一般消費者が欲しがらないものは「コンシューマ製品」とは呼ばないです。というか事例を見ても完全に企業向けですよね、これ。
縦書きの本だったらMeTilTranというのが便利です。
http://no722.cocolog-nifty.com/blog/metiltran/index.html
MeTilTran、発想は面白いけど、画像をソースとして扱うと検索ができないのであまりそそられないですねぇ。あと、こういう配布条件のツールに自分の本を預けたいとは思わないというのも……。
出遅れてますが、こんなのどうでしょう。シェルスクリプトの自炊PDFのKindle向け最適化ツール。
http://sasasin.net/docs/?Kindle
情報ありがとうございます。これって画像を抜き出して新たなPDFを作る手法ですよね(ChainLPと同じ?)。
せっかくOCRで文字情報も入れたPDFから、それを削ってしまうのはやるせないので、私は当面pdfcropで行こうと思います。pdfcropなら奇数・偶数ページで異なるマージンを指定できますし。
＃とはいえ、Kindleの検索機能は思いのほかしょぼいのですが:-(
画像を抜き出して処理してます。
時間はかかってしまいますが、OCRは再度つければよいのでは？
pdfcropは幅指定が必要ですが、こちらは自動判定でcropです。(push!!
幅も指定できますが、自動cropの前処理として、ページ数を示す文字やヘッダーを削るためのものです。
ScanSnapのOCRは、いじったPDFを対象にしてくれないんですよね……。
あと、画像として扱う場合、KindleだったらPDF化せずにそのままzipした方がフルスクリーン使えるから良いのでは?
ScanSnapで作ったPDFのメタデータを、作りなおしたPDFに捩じ込めばOCRをかけなおすことができます。
pdftk 元.pdf dump_data output メタデータ.txt
pdftk 新.tmp.pdf update_info メタデータ.txt output 新.pdf
せっかくなので、上記をpdf2mobi.shに組み込みました。
PDFだとフルスクリーンではありませんが、活字に関して言えば「余白付きzipをフルスクリーン表示」「余白なしPDFにKindleが余白を付けて表示」なら等価かなと。zipではなくPDFにしたのは、初回の待ち時間が悲惨で、ページめくりもPDFより遅く感じたためです。
ほほう! それは耳寄りな情報です。あとからOCRにかけられるのであれば、画像化を毛嫌いする理由は少なくなりますね。時間を見つけて使ってみようと思います。ありがとうございました。