ただのにっき

■ わさます忘年会だった

わさます忘年会だったので久しぶりに秋葉原に向かった。駅ビルがAtreになってリニューアルオープンしてから初めてのアキバなので、アトレ口から降りてみたんだけど、およそアキバに似つかわしくないおしゃれビルになってた。中を歩いてるカップルまでなんか雰囲気違うし! ……などとビビりながら歩いていたんだが、聞こえてきた館内アナウンスが見事にロリ声で安心した(笑)。地元(?)で調達したんだな、きっと。

会場は10ヶ月ぶりのKIICHIで、こっちもリニューアル後はじめて。店員がメイドさん(しかも2人体制)になっててびっくりしたけど、別に変なロールプレイを強制されるわけもなく、いたって普通の対応でした。まぁ、ノリはアキバ的なんだけど。リニューアルでテーブルレイアウトなんかは変わったけど、ポスター類などの方向性に変わりはなく、相変わらずその方面の人には安心できる空間だった。

宴会後はなぜかみんなでまだ開いていたアキヨドに繰り出して、お互いに散財同調圧力をかけあうという恐ろしい二次会に。キネクトやらトルネやらが買われておりました。おれもうっかりレンズとか買わなくてよかった……。

■ 自炊PDF制作をrake化してみた(途中)

目的と手段が入れ替わってる自炊本シリーズ第N段。

自炊本制作はこないだベストプラクティスとか書いた以上、セッティングはだいたい詰められたんだけど、まだ作業が最適化されてないのが気に食わない。具体的には余白をきれいに除去するためにpdf2kindleを何度も実行してパラメタを詰めるところね。PGM→PNG化の処理を繰り返すために、スクリプトの特定の関数だけを実行したいわけだ。

そのためにいちいちスクリプトをいじるのはアホらしいし、そもそも複数の工程が含まれているんだからここはRakeの出番だろ。というわけでRake化してみているのだが、白状すると自分でRakefile書くの始めてなんだよな、今ごろ何言ってんだという話だけど*1。まぁ、いい練習台を見つけたということで。

で、それっぽく動くようなものはできたものの、依存関係がまだうまく解決できないんだよなぁ。ソースが1個しかないけど、途中の生成物が複数できる(しかも個数未定)場合のうまい指定方法がわからん。

Kindle最適化PDF生成の工程がどうなってるかというと、こんな感じ:

1. ScanSnapでスキャンしたPDFから、1ページ単位の画像(pgmフォーマット)を切り出す。スクリプト実行前には何個のpgmファイルができるかわからない。
2. pgmファイルから余白を削除したpngファイルを作る。ここは1対1の関係なのでまさにRakeの面目躍如。ちなみに何度も実行してチューニングしたいのはこの工程。
3. 元PDFのメタデータを別途抽出する。
4. pngファイル群を結合し、メタデータを設定して、最終的なPDFファイルを生成する。

問題は途中の工程で生成される画像ファイルの数がわからないことで、ファイルリストが作れない。結果として最初のタスクの依存関係がうまく書けない。たぶんRakeマスターなら知ってるうまい技があると思うんだけどなー。

なお、工程1をやめて、最初から(PDFではなく)画像としてスキャンするというソリューションもあるにはある。これは最終手段。

■ 自炊画像を使ってmobiファイルを作ってみた

なんとなしにmobiファイル(Kindle特有の電子書籍フォーマット)の作り方を探っていたら(参考にしたのは「電子書籍の作り方 (Kindlegen)」とか)、なんだかずいぶん簡単なことがわかった。ようするにHTMLにメタ情報を与えるだけじゃないか。ePUBと同じなんだな。てことは、画像を埋め込んだHTMLを作れば、自炊本もmobiにできるってことか。

ということで、ちょっと作ってみたのだ。pdf2kindleで余白をカットしたPNGを生成してあるので、それらすべてをimgタグに挿入したHTMLを生成。上のリンクを参考に、画像ごとに改ページを示す特殊のタグを挿し込んでやれば、1画像1ページになる。メタ情報opfファイルも作成して、Linux用kindlegenに食わせたら、けっこうあっさりできた。サイズはPDFとさほど変わらない(少し大きいかも)。ImageMagicでPDFを生成するのに比べると、1/100くらいの時間でできた。作るという観点だけから言えば、こっちがいいなぁ。

で、さっそくKindle3に読ませてみたわけだが、結論から言うとダメだこりゃ(笑)。

まず、上の方に妙な余白がある。上のスクリーンショットを見ればわかるが(左がPDF、右がmobi)、なぜか純正フォーマットであるはずのmobiの方が表示面積が狭い。たとえ文庫本でもできるだけ大きな字で読みたいので、これは良くないなぁ。まぁ、画像だけからなるファイルは想定外なんだろうけど*1

あと、PDF表示ではできるコントラスト調節がmobi表示ではできない。それから、Kindleを横持ちにしたときに表示が「Fit to width」相当にならない!(Fit to heightのみ) これはつまり、縦長の画像からなるページは小さく縮小されて端に寄せて表示されるだけ、拡大されない。mobi表示は本当にちゃんとテキストからなる専用書籍のための機能なんだなぁ。

というわけで、自炊本のためにはPDFが最適だということを確認したにすぎないのであった。まぁ、TEXTやHTMLで長いテキストを入手した時には自分でmobiが作れるようになっておくのはいいことなので、それはそれでいいのだけど。でもまぁ、メモリが潤沢なPDF生成環境は欲しいやねぇ。そのためにVPSを一個借りるか(ぇ