Perth

Perthはオーストラリアの西にある都市だ。西部ではおそらく最大の都市だろう。しかし、それでものんびりとしたところだ。
西部の人は東部の人が忙しすぎるという。西部のゆるやかな時の流れの方が人間的な生活にふさわしいと考えている。
Perthから少し離れたところにワイナリーや動物園がある。動物園ではコアラに触れることもできる。日本では考えられないほど距離が近い。
ときどきカンガルーの肉を試食できる機会がある。よほどうまく調理していない限り、それほどうまいとは思えない。何かの代用品には成りえるが、それ自体がメインの料理にはならないと思う。もちろん、それをメインにしているレストランがないわけではない。それらの店はプロだから調理がうまいのであり、家庭でカンガルーの肉を料理しようとするのは賢明ではないと思う。

ミラノ

大分前のことだがミラノに行ったことがある。
旅の途中によっただけだが、急いで観光しようと思えば、一日でもそれなりに見てまわることが出来る。多くのヨーローッパの街がそうだが、大聖堂や広場を中心に見てまわればよい。
ミラノの大聖堂の近くではつまらない紐を売りつけられそうになった。サッカーファンなら意味があるのかもしれないが、私にはただの紐にしか見えなかった。売りつける相手を間違えている。
また、大聖堂近くにショッピングアーケードがあり、そこで昼食としてパスタを食べたが、非常に高かった。うまいことはうまい。しかし、値段の価値があるかといえば、おそらくない。
文句ばかり書いたようだが、街自体は魅力的だ。観光する価値は十分にある。

Plustek OpticBookによる電子ブックの作り方(3)

OpticBookを使っていろいろな本をスキャンしてみた。
その結果、いろいろな問題点がみえてきたので報告する。
まず、500ページの本をスキャンしたところ、ImageFolioがメモリ不足で終了してしまった。ImageFolioはスキャンしたイメージを表示する際、メモリに読み込んだままにするようだ。これはある意味当然だ。そこで、連続スキャンする場合は、PCのメモリに応じて一旦終了し、複数回に分けてスキャンする必要がある。
また、500ページをconvertで変換しようとしたら、これもメモリ不足で動作しなかった。これは致命的なので、convertでは多くのページの本を作成できないことがわかった。逆に、PageManagerを使うとスムーズに変換できる。さすがに500ページをPageManagerで扱うとかなり重くなる。しかし、辛抱強く待てば、動作はしているので最終的な結果は得られる。
convertはPDF変換だけでなく、ページの回転も行うことができるが、DocActionで偶数ページのみ回転するように指定するだけでconvertを使う必要はなくなる。やはり、添付CDのツールだけで完結して操作を行うことができるようだ。
偶数ページ回転の場合の所要時間を測定してみた。393ページの書籍を偶数ページのみ回転させながらスキャンしたところ、99分かかった。前回は158ページに28分かかった(11s/page)が、今回は393ページで99分だった(15s/page)。よって、回転によって１ページあたり4秒ほど余計にかかるようだ。しかし、この差は純粋に回転処理のオーバーヘッドではない。ページ数が増えるとImageFolioを再起動する手間や、重い本をめくる手間など確実に様々なオーバーヘッドが増える。その総合的な影響である。特に、スキャンを中断したとき、偶数ページで中断しておかないと、次のページから反対にスキャンしてしまうことになる。このような場合、もう一度スキャンをやり直さなければならないし、余分なイメージを削除することも行う必要がある。
また、393ページでもPageManagerの処理はかなり重くなる。今回は、そのオーバーヘッドは測定しなかったが、確実に数分は余計にかかる。

誰がAndroid版iPadを作るか？

Androidは徐々に浸透しているようだ。iPhoneの閉塞性を追い風にして、徐々にかつ着実に勢力を伸ばしつつある。今回のアンテナ問題はiPhoneにとってマイナス要因だが、一時的なものに過ぎないだろう。アンテナのせいでAndroidが選択されているわけではないということだ。やはりAndroidは安く、しかも便利だということだ。
iPhoneに対してAndroidが対抗馬になるならば、iPadに対しても対抗できるだろう。実際、iPadにはiPhoneほどの優位性はない。よって、どの会社もAndroid版iPadの市場を支配しようと狙っている。最初の製品はASUS Eee Padだろうか。
この分野に日本メーカーが参入できるかで、世界市場における日本の存在感が試されるだろう。
SharpはUbuntuに傾倒しているが、Androidへの対応は進んでいるのだろうか？また、iPadサイズのマシンを開発できるのだろうか？
SonyはAndroidの十分なノウハウを持っているし、ネットワークウォークマンのノウハウもある。それをiPadサイズで実現できるかが問題だ。
しかし、これ以外のメーカーが開発できるのか疑問だ。国内のPCメーカーとして知られるNECや富士通、Panasonicなどはいずれも実現できないだろう。試作機は作れても製品化はできないだろう。日本の存在感は相変わらず小さいままかもしれない。

Plustek OpticBookによる電子ブックの作り方(2)

OpticBookにはScanSnapに比べてメリットがある。そこで、OpticBookでより効率的な作業の方法を考えた。
スキャン作業は、これ以上効率を上げることは難しい。スキャンを効率化するには、もっと特別なスキャナが必要だ。そこで、それ以降の処理に要する時間を短縮する。
ページの回転とPDFの作成はいずれもImageMagickを使って容易に自動化できる。具体的な手順を説明する。
まず、スキャン処理においてDocActionの設定を変更する。自動切り抜き、自動傾き補正はもちろんだが、保存設定で保存フォルダを指定し、スキャンと同時に保存するようにする。また、日付でなく連番にする。連番だとページ番号に対応するので、どのページを回転させればよいかがわかりやすい。このように設定した後、全頁をスキャンすると、ImageFolioでは何もせずに終了してよい。
ページを回転するには、大まかに偶数ページと奇数ページのどちらを回転させるべきか決める。各ページを回転させるには、ImageMagickのconvertコマンドを使う。
convert -rotate 180 image%05d.jpg image%05d.jpg
ここで、%05dの部分に回転すべきページ番号をあてはめる。簡単なプログラムを書いて、バッチファイルを生成すればよい。例えば、奇数ページのみ回転する場合には以下のようなバッチになる。
convert -rotate 180 image00001.jpg image00001.jpg
convert -rotate 180 image00003.jpg image00003.jpg
:
ここで、作業を楽にするために必ず回転すべきページが奇数か偶数かのどちらかになるようにあらかじめ調整しておくとよい。つまり、たとえ空白ページでもスキャンしておくか、きれいな空白ページを生成して挿入するかいずれかだ。小さな空白イメージを用意しておき、それをconvertで任意のサイズに変更すればよい。
convert -resize 1000x1000 white.ipg image0000X.jpg
サイズは他のページに合わせて決める。多少いい加減でもかまわない。表紙と同じでよいだろう。
最後に、convertで全頁を結合してPDFへ変換する。
convert *.jpg output.pdf
このような方法を用いると合計25分を要した作業(2),(3)は5分ほどに短縮される。手作業で回転していた分をほぼ0にできる。
少数のページを回転するときは、convertを使う方が面倒なので、いったんPDFに変換した後でPDFの回転ツールを利用した方がよい。
ScanSnapには自動でページの上下を判定し、回転してくれる機能がある。このような機能がDocActionにあれば、もっと楽になるはずだ。convertを使う必要は全くなくなる。早く改善してほしいものだ。

補足
と書いた後で、DocActionに画像の向きを設定するオプションがあるのに気付いた。当初は「自動回転（アジア言語には適用されません）」とあるので、使えないかと無視していたが、偶数か奇数かで180度回転するオプションがある。これでおおまかに回転させ、もしも偶数と奇数が違った場合はさらに全頁を回転させ、残りのページをPDFツールで回転させるとよいだろう。

Plustek OpticBookによる電子ブックの作り方

Plustek OpticBookはブックスキャナを名乗るフラットベッドスキャナだ。裁断できない本をスキャンするのに役立つ。今回は4600を用いた。ブックスキャナの特徴は筐体ギリギリまでフラットベッドが続き、本を押し付けても隙間が空かないため、きれいにスキャンできることである。
しかし、OpticBookでスキャンするには、裁断する必要はないものの、自分で１枚ずつめくりながらスキャンするしかない。
OpticBookで電子ブックを作成するには以下の手順で行う。
(1) スキャン
OpticBookで１ページずつスキャンする。スキャンしたページはJPEG形式で保存される。ここで、形式に拘る必要はない。しかし、マルチメージのTIFFやPDFは他のツールが対応していないのでやめたほうが良い。ちなみに、このとき本の最初のページからスキャンするとよい。スキャンの順番はイメージファイルの名前に関係するので、順番どおりにしたほうが良い。また、スキャンのしかたにもコツがある。99%までいけばヘッドがもどるだけなので、次のページをめくり始めることができる。そうしないと倍の時間がかかるだろう。なお、DocAction余白を切り取ってくれるので、自分で範囲指定する必要はない。
(2) ページの回転
OpticBook特有の処理である。１ページずつ本をスキャンしようとすると、偶数ページと奇数ページの向きが逆になる。奇数ページは順方向、偶数ページは逆方向だ。そこで、偶数ページだけ180度回転させる必要がある。OpticBookにはPresto ImageFolioが添付されており、インストール後はスキャンするとこのソフトが起動する。しかし、ImageFolioはブックスキャン専用ではないので、あまり気の利いた機能がない。例えば、180度回転させるには、90度回転を２回行う必要がある。また、スキャンしたイメージを一度に保存する機能もないので、何回も回転と保存を繰り返す必要がある。
(3) PDF作成
ImageFolioで読み取った複数ページを特定のフォルダに保存した後で、Presto PageManagerを起動する。保存したフォルダを選択するとページイメージの一覧が表示される。PageManagerには180度回転メニューがあるので、ImageFolioの代わりにPageManagerで回転させても良い。ただし、PageManagerではイメージが縮小表示されるので、上下が判別しにくい。回転すべきページを間違える可能性がある。ImageFolioは倍率１倍で表示するので確実だ。PageManagerですべてのイメージを選択した後、スタックメニューを選択すると、ひとつにまとめてくれる。ただし、この段階ではファイルはまだばらばらだ。デスクトップ上で重なって表示されるだけだ。次に、スタックをPDFで保存する。これで完成だ。PageManagerもあまり気が利かない。例えば、全部のページを選択するメニューがあれば簡単にできることが、それがないためにスクロールしながら全部のページを選択しなければならない。
以上の作業の所要時間は以下のとおりである。
(1) スキャン：28分
(2) ページの回転：20分
(3) PDF作成：5分
ちなみに、ページ数はPDFベースで158ページだった。サイズはB5版だ。前のA4,414ページに比べてかなり遅いことが分かる。

ScanSnapによる電子ブックの作り方

電子ブックリーダとなるマシンが増えてきているが、肝心の電子ブックが増えない。そこで、しばらくは手持ちの本を自分で電子化する以外に電子ブックリーダを利用する機会はなさそうだ。
電子ブックを作るには大きく分けて２つの方法がある。ScanSnapを使う方法とPlustek OpticBookを使う方法だ。これ以外の方法はコスト的に一般人が手を出せるものではない。もっとも最近では非常に安い価格で電子化してくれるサービスもあるので、一般人はむしろ自分でせずにそういったサービスを利用すべきだろう。ここでは、自分で電子化しようとする奇特な人のために基本的な方法を紹介する。
ScanSnapは、いわゆるフラットベッドスキャナではない。強いていればADFスキャナというべきだろうか。ADFはA4用紙を１枚ずつローラーで巻き取り、スキャン部へ送る。そのため、複数枚でも効率よくスキャンできる。しかも、PDFに変換してくれる。なお、ここではPDFに変換できた時点で電子ブックになったとみなす。その意味ではScanSnapはほぼ完璧な電子化ツールだ。
しかし、ScanSnapを使うためには書籍を裁断する必要がある。しかも、紙送りに失敗しないようにきれいに裁断しなければならない。一番安上がりな方法はカッターと定規を使う方法だ。たくさん電子化しようとするなら裁断機の導入も検討すると良い。それほど高くはないが、万は超える。
カッター、定規、ScanSnapで１冊の本を電子化するのに要する時間は約24分だ。その内訳は、以下のとおりである。
分断（背表紙を切り取り、数枚単位のまとまりに荒っぽく分ける）：14分
細断（カッターできれいに１枚単位まで切り分ける）：7分
スキャン：13分
一番面倒そうに思えた細断は、実は大して時間もかからない。むしろ荒っぽく本を破る分断が一番の重労働だ。スキャンはScanSnapに用紙を供給し続けるだけなので、お茶を飲みながらでもできる。
これでも分断は短いほうだと思う。というのは、今回電子化した本は論文集というもので簡易製本されたものだからだ。これがもっとしっかりした本なら、壊すだけでも時間がかかるだろう。
ちなみに、ページ数はPDFベースで414ページである。スキャン時間は単純にページ数に比例する。