Kindle Voyage 速報レビュー

Pocket

Kindle Voyage買いました。解像度厨としてはとりあえず高解像度化されたら買わないと思ってw。Paperwhite 第一世代以来のKindleです。

特徴は、

  • 1080×1440/300dpiに高解像度化(Paperwhiteは212dpi)
  • 更に薄型化
  • ライトの自動調節
  • 両サイドにページめくり用タッチセンサー
  • ガラス化

など。高解像度化に加え、タッチセンサーでページめくり(しかも両サイドとも順送り可能)が快適そうなので購入。キャンペーン(広告表示)無しのWi-Fiモデルをチョイス。

DSC00485

初期印象としてはかなり良いです。ガラス化に伴いフレーム枠との段差がなくなったのでデザイン的にスッキリしてます。ぶっちゃけこれなら両サイドのタッチセンサーなくてもいいかも(笑)。ガラスとはいえ特殊エッチング加工がしてあるらしく、映り込みなどは問題なし。写真はフラッシュでバウンス撮影してますが特に光が映り込んでるようなこともないですね。

タッチセンサーはバー部分が順送り、ドット部分が逆送りで左右対称。つまり左右どちらの手でもっても読み進めることができます。Paperwhiteでは、画面右寄り3cmくらいが逆送りになってるので、右手持ちの時には親指をちょっと伸ばせば順送りになりますが、このちょっと伸ばすとか、左右で作法が違う部分が地味にストレスなんですよね。今回は完全左右対称で読み進められるのが大きな進歩だと思います。自炊ビューワーアプリや一部電子書籍プラットフォーム公式ビューワーアプリなら設定でそうできるものもあるんですが、e-ink端末では珍しいかも。やっとか!って感じです。感度は三段階で、「中」だとたまに反応しないのでもっとも敏感な「弱」にしてますが、逆に誤反応に気を遣います。これ持ち方で最適値がかわる気がするので、ホームから設定画面にとばずとも、ライトの明るさのように読書画面からサクっと切り替えられるといいなぁ、とか。

レスポンスはPaperwhiteでもそう不満はなかったですが、こちらも充分速い。高解像度化のあおりでモッサリ化、なんてことはないです。

反転無しでも残像感はほぼないかな。ライトによる”Paperwhite”感も同等レベル。自動調節の恩恵はまだこれから評価というところです。

アップで撮ると解像度はこんな感じ。新規搭載(?)の「筑紫明朝」で、下から三段目のフォントサイズで表示。字体は「筑紫明朝」の方が好きですが、「明朝」の方が滑らかで擦れ感が少ないかも。これくらい解像度があるとコミックも結構イケます。小さい文字やトーンも割と綺麗。

DSC00497

すぐにケースをつけてしまったのでなんともですが、前面も背面もフラットになってホールド感が若干落ちた感があります。あと電源ボタンが背面なのは微妙。今回フリップ型のカバーケースをつけたので、いざ使おうとフラップをめくって背面側においやるとボタンが隠れて押せないという事態に…。電源ボタン押してからフラップをめくる習慣にすればいいだけなんですが、いまんとこ馴染めないです。自宅利用の時はPaperwhiteの時みたいに片手保持ベルトを作って使いたいところ。

 

まだ一冊も本を読み切ってないですが、とりいそぎの速報レビューとして。SH-04Fのサイズが片手持ちとしてはほぼ理想的なサイズで、それが5.4インチ、Voyageが6インチなので大差なく、かつあっちの方が1080×1920と高解像度なわけですが、あちらは9:16なので、コミック用としては無駄も多いんですよね。計算してないですが実効解像度は似たようなもんじゃないかと。ePub小説だと9:16でも最適化されるし、暗いところで読むσ(^^)的には白黒反転機能が重要なのでスマフォでいいかなという感じ。むしろコミック向け?

自炊データに関しては追って評価します。

電子書籍リーダー PRS-T3S

Pocket

前エントリで最近ePub制作仕事をしてると書きましたが、ちょうどそんな折り、楽天でkobo gloとkobo miniが半額セールに。しかも最近楽天使ってなくてすっかり忘れていたポイントが2,000pt以上あって、千円ちょいで買えてしまう状態だったので、kobo gloを注文しました。

がしかし、優勝セールの慌ただしさでちっとも配送されず。色々ePub表示の仕様をリサーチしているうちに、SONY Readerの最新モデルPRS-T3Sが評判良いということがわかり、2,3日迷った挙げ句ゲトしてしまいました。初代PRS-350から3年ぶり、e-ペーパー機としてはKindle Paperwhite 2012から1年ぶりの購入です。正直自炊小説はbREADERがあればいいやと思ってたんですが、上記のePub仕事の検証機としての大義名分と、あと最近電車で読むことが増えて、iPhoneのサイズだと座った時に視距離が離れてて文字が小さい(または大きくするとページめくり頻度が高くなる)なと思って。

T3Sが手持ち機種に比べて良いところは、

  • ページめくりが高速され、白黒反転もほぼなくなった
  • 内蔵ブラウザでSONY Reader Storeだけでなく紀伊國屋ストアからも買える
  • Facebook連携
  • Evernote連携
  • microSDスロット

などです。eペーパーの宿命と言われていためくり時の白黒反転が独自制御によってほぼ見えないレベルになっています。もともとメチャクチャ気になるってほどではなかったですが、ないに越したことはありません。特に最近の機種は白黒反転をしないまま数ページはめくれるように進化してきたんですが、それが逆に数回に一回忘れた頃にやってきてリズムを乱す、みたいなひっかかりになってました。本機は仕様上4時間に1回すればいいんだとか。

内蔵ブラウザは確かに便利だけどやっぱりもっさりしてるし本を物色する時は液晶タブレットやPCを使うかなー、という感じ。Facebook連携は面白そうだけど、何をどう勝手にポストされるかわからないのでちょっと慎重になりますね。koboも先にiPadアプリを入れて試しに認証してみたんだけど、以前koboから色々ポストさせてた友人もいつのまにかOFFにしてた。やはり色々暴露されすぎてイヤになったとw。電子版ならではの楽しみを付加したい気持ちはわかるんですが、やはりまだシーズ先行感が否めないですね。でもkoboのバッジはちょっと楽しそうかも。

そんな感じで微妙だと思っていたネット機能ですが、Evernote連携はちょっといいかも。大きくわけて、

  • 指定ノートブックをダウンロード
  • Cleary連携

があります。ClearyはInstapaperやiOSのリーダーのように、ゴチャゴチャしたWebページをすっきり本文コンテンツだけ抽出して見せてくれるブックマークレット的なサービスですが、これに登録して簡易化したコンテンツを、自動的に同期しておいてくれるのです。対応ブラウザにプラグインを入れておけばサクっと登録できるのでヨサゲ。ただし残念なことにSafariにはアドインが存在しない模様。

■ハード面

まずKindle Paperwhiteより更に軽いという軽量さは良いです。両手にもって比べるとわかるレベルです。それでいてReaderにはハードボタンあります。これはまぁ好みの分かれるところでしょうが、個人的にはボタン1発で確実にしかも素早くめくれるのはやはり気持ち良いです。まためくり以外のメニューを出すのに、Kindleは見えていない特定部位をタップするわけですが、これがいつも一発で出せなかったりする(まぁ、色々なリーダーやアプリを使ってて画面上部タップだったり画面中心タップだったりダブルタップだったりして混乱してる方も悪いんですがw)。この当たりはハードボタンでサクっとやれるのが良いです。それでいてPaperwhiteより軽いんだから文句はいわせねぇぜ、というSONYのドヤ顔が浮かびます。ただ、山口さんもPC Watchのレビューで書いてるように、ボタン形状がアイコンをそのまま象ったもので、全般的に尖っていて指にチクチクささるのが気になります。前モデルよりはマシになったらしいですが、これは止めて欲しい…

またページめくりは快適な一方、ホーム画面で本を選んだりといった動作はあいかわらずトロいです。

ちなみに本体カラーは白を買いました。外枠の色は動画メインなら黒、書籍メインなら白というこだわりで。あんまりテカテカだったら考えるところでしたが、ギリギリ許容範囲かな。あんまりマットだと手垢がつきやすくなるでしょうし。まぁ、画面の周囲に細い黒枠が存在するのであんまり一体感ないですけどねw。これはタッチ検出用の赤外線センサ部になるのかな?だとすると白くするのは難しいんでしょうなぁ。

Paperwhiteやkobo gloに劣る点としてはフロントライトがないところ。gloのライトはムラムラで焼けた古本みたいになるのでむしろいらないですが、Paperwhiteの文字通り綺麗な白色になるライトはたとえ暗所で使わないとしても良いものです。まぁ、暗いところではeペーパー+フロントライトよりも、白黒反転(黒地に白文字)させた液晶の方が目が疲れないので、そういう時は素直にiPhoneやiPadやNexus7を使います。ってことでオプションのアンコウライトは買ってません。

■ソフト面

UI面での不満は画面タップでページめくりができない点です。スワイプのみ。右手で持った時はハードボタン届かないので、画面タッチで読み進めることになるんですが、まいどスワイプするのがめんどくさい。Kindle Paperwhiteの記事でも書いてますが、画面の左右端どちらでも進む方向にアサインできてほしいですね。

PRS-350からの踏襲ですが、明るさとコントラストを調整できるのもナイス。自炊書籍で微妙に薄かったりした時にリーダー側で補正できるのは非常に助かるのです。プリセットはたいてい役立たずで「カスタム」を選んで調整することになるんですが、欲を言えばこのパラメーターをデフォルトにしたりプリセットにできるといいなぁ。

フォントも代わってるっぽいですが、特に大きな不満はなし。行間は調整できると良かったかなー。

自炊面でいうと、PDFを表示した時にステータスバーがなくなり758×1024ピクセルをフルに活用でき
るようになった点は特筆に値します。自炊のスキャン書籍をeペーパー端末で読む時には解像度は1ピクセルたりとも無駄にしたくないものです。残念ながらePubの場合は引き続きバーが表示されページ番号が出ちゃいます。今後はePubで自炊しようと思ってたのになぁ。当面本機用のフォーマットはPDFを使うことになりそうです。ただ旧機種であったように綴じ方向の設定が無視されてしまうことはなくなっているので、特にPDFで困ることはなさげ。また範囲手動指定可能な余白カット機能もついてるので、わざわざ本機専用の解像度でドットバイドット表示できるPDF/ePubを作り直さなくても、充分高解像度なデータをそのまま放り込んでやればそこそこ読めちゃうのかも知れません。容量食われてもmicroSDを使えばいいんですし。レスポンスが落ちたりするかは追々実験してみます。逆にそんな未最適化のデータがあんまりないw。

オタ的にはスタンバイ中の壁紙が自分でカスタマイズできるのも嬉しいポイントです。旧機種からあった機能ですが、解像度が上がってより綺麗に表示されるようになりましたw。Kindle Paperwhiteも昔のように世界の文豪シリーズでオッサン&オバサンが入れ替われ井出るなんてことはなくなりましたが、やはり自分でカスタマイズしたいものです。

■自炊レシピメモ

久しぶりにChainLPが活躍しそうです。おおまかにはこちらのPaperwhite用レシピに乗っ取ります。ファイル出力タブでKindle対応のためのコーナー色チェックが不要になる位ですかね。最近はページ補正タブのノンブル転送のところの「余白付け」をオンして、かわりにトリミング&余白設定の下余白を0にしてます。

出力解像度はPDFなら758×1024(=ハード解像度)、ePubなら738×965でいいみたい。

あとヒストグラム設定で少し濃いめにしておくと、端末側でカスタム指定しなくてよくなります。

自炊ePubのためのあれこれ覚え書き

Pocket

先日、ちょっとした私家版書籍の電子版製作を依頼され、先月はあれこれ試行錯誤していましたが、ようやくそこそこ形になったので培ったノウハウをメモしておきたいと思います。作業環境はMacです。

■仕様

  • 原稿はWordでレイアウトされたファイル
  • 日本語縦書き
  • 本文は明朝、見出しはゴシック、引用文として丸ゴシック
  • 図版は無し(これがあったら更に大変だったことでしょう…)
  • リフローで作る
  • 汎用フォーマットとしてePub、Kindle用に別途mobiを作成
  • KDPによる出版などはせず、自サイトでの無償配布のみ

てな感じです。

■作業手順概要

元ファイルがWordだったので、一太郎・玄2013で読み込み、ePub書き出しをしてみました。元Wordでのレイアウトがスタイルを駆使したものではなく、個別指定箇所がほとんどだったため、微妙なマージやフォントサイズ指定の差異で、かなりアドホックなCSSクラスが作られてしまいましたorz。

一太郎ではePubのソースは一切いじれないので、そこからはSigilで手作業。ただし、Sigilは縦書きに正式対応したePub3.0には対応しておらず、Android系やWindowsストア系のePubリーダーアプリでは縦書きにならない問題が発生(iBooksやmobi化してKindle PaperwhiteではOK)。結局ePub3.0化を決意して、テキストエディタ(Sublime Text2を使用)でちまちま修正することにしました。Sigilは非対応なタグを強制的にePub2.0仕様に書き換えてしまうので、おそらく一太郎出力時点でePub3.0だったものが色々書き換えられてしまったんじゃないかと思います。今後はSigilを使わずにエディタを使おうと思います。Sigilの出力したファイルをePub3.0互換に書き換えるには、EPUB日本語文書作成チュートリアルが参考になりました。

Sigilの便利な点はePubを読み込み、ePubを書き出す、という作業が自動で行える点です。ePubは実際にはxhtml、css、画像その他のメタファイルを一定のフォルダ階層ルールに沿って配置し、zipで固めて拡張子をepubにしたものです。テキストエディタ等で手編集する場合は、デバッグ作業をする度に、zip化->リネームをしなければなりません。しかも、mimetypeというファイルがアーカイブの先頭になければならない、というルールがあり、単純にアーカイバにフォルダをドロップ、というわけにもいきません。具体的には、Macのターミナルで、こんな感じで作業しました。カレントディレクトがソースフォルダhogeのルート(トップ)にいるとします。

zip -0 -X ../hoge.epub mimetype
zip -r ../hoge.epub * -x mimetype

1行目で新規アーカイブhoge.epubを1つ上の階層(ソースフォルダと同じ場所)に作成し、mimetypeのみ追加。2行目で同じアーカイブにmimetype以外の全てを追加、という手順ですね。アーカイブの拡張子はepubが直接指定できているのでリネームは必要ありません。ターミナルの履歴を使えばさほど手間ではないですが、いっそバッチやドロップレットにしてしまうのも手かも知れません。

OSX MervericksではMac版iBooksが搭載されているので、できたファイルをダブルクリックすればiBooksで開き検証ができます。Mervericksが出る前はMurasakiを使っていました。Mac版iBooksはデフォルトではページ中心に隙間があいた2ページ表示ですし起動もややもっさりしていおり、更には単に元ファイルを上書きするだけでは更新されず、ライブラリからアイコンを削除しないと変更が反映されないこともありました。なので、Mervericksであってもデバッグ作業はMurasakiの方が効率が良いかも知れません。たぶんレンダリングエンジンは同じWebKitベースだと思います。

■縦書きにする

色々試しすぎてどれが効いているかやや微妙ですが、憶えてる限りでは、スタイルシートに、

html {
    writing-mode: vertical-rl;
    -epub-writing-mode: vertical-rl;
    -webkit-writing-mode: vertical-rl;

    line-break: strict;
    -epub-line-break: strict;
    -webkit-line-break: strict;

    word-break: normal;
    -epub-word-break: normal;
    -webkit-word-break: normal;

}

としました。色々な環境に対応できるよう、-epub-と-webkit-のプレフィクスを付けた指定も重複して指定してあります。どの環境でどれが必要になるかまでは検証してません(笑)。

あとはページ送り方向を右綴じ準拠にする為、content.opfのspineタグの部分に、

<spine page-progression-direction="rtl">

のようにpage-progression-direction属性を追加しました。

■マージン指定に関するTips

段落毎などにマージンをいれたい場合、margin-right(段落の手前)、margin-left(段落の後)を使います。Kindle出版ガイドに、「emではなく%で表示しないと、文字を拡大した時に無駄に行間が空いちゃうよ」と書かれており、試しに%に書き換えてみたんですが、iBooksでヒドいことになり戻しました。どうも基準となる100%の幅として画面縦のピクセルを使っちゃうようです。ウインドウの縦の長さを変えると、横にマージンが広がる、という状態にw。縦書き対応が不十分なんですかね。あるいはright/leftではない別の指定方法があるのかも。ググるとmargin-beforeみたいな物理方向に依存しない指定方法を検討はされてるみたいですが、今のところ正式には決まってないみたい(ePbu3.0自体がまだドラフトなんですよね)。

まぁ、KDPで出版するわけじゃないので、em指定に戻しました。Kindle Paperwhiteでも特段不都合出てないような気がします。

■縦中横を指定する

縦中横とは、縦書き文中の英数字、記号などが横に寝てしまっているのを正立させる指定です。丸数字や2桁程度の数字に適用させました。スタイルシートにtcyというクラスを作り、必要箇所にspanタグで指定しました。

/* 縦中横(丸数字などを正立させる) */
span.tcy {
text-combine: horizontal;
-epub-text-combine: horizontal;
-webkit-text-combine: horizontal;

text-indent:0;
}

■フォントを埋め込む

これが一番苦労しました。本文に丸ゴシックがあるのですが、多くのリーダーは明朝とゴシックが1書体ずつ入っているのみ。また手持ちの初代SONY Reader PRS-350は内蔵フォントをCSSで指定することもできないっぽい(後継モデルは大丈夫らしい)。iOS版iBooksでは「ヒラギノ丸ゴ W4」が追加ダウンロードできるので、CSSで指定してやればOKでした(Mervericks版は標準でOK)。

ハードウェア内蔵フォントが使えないとなると、ePubに埋め込むか、リーダー自体に追加するかですが、後者はユーザにリテラシーが必要なので今回は除外。しかしePubに埋め込んで配布する場合はライセンスの問題が発生します。一般に売られているPC/Mac用の商用フォントは埋め込み禁止のものがほとんどです。使っているフォントのみ埋め込む「サブセット化」ならOKというのも聞くのですが、サイトの記載だけだといまいちはっきりせず。フリーの丸ゴシック系フォントはないものかと探したところ、「モトヤマルベリ3等幅」というのが、Android4.0搭載用にApacheライセンスでオープンソース化されていることが判明。こちらで配布されています。MTLmr3m.ttfが「モトヤマルベリ3等幅」、MTLc3m.ttfが「モトヤシーダ3等幅」という角ゴシック体のようです。今回は商用配布でもないのでコスパ優先ということでこちらを採用することにしました。Apacheライセンスなのでコンテンツ中(配布サイトでもいいのかな?)にライセンスを明記する必要があるかも知れません。また、埋め込みフォントならばPRS-350でも有効っぽかったので、角ゴシックも埋め込みで対応することにしました。

なお、これらの2書体を縦書き用にカスタマイズしたというKoboMaruとKoboNakuが公開されているようですが、試したところ記号がズレてしまってダメでした。

これら2書体のをそのまま埋め込むと、130KB程度だったファイルサイズが一気に3MB位になってしまいました。iBooksでは不要なものなのでちょっと悔しい。かといってiBooks向けとそれ以外向けでePubを複数バージョン管理するのもしんどい。ということで、サブセット化をしました。武蔵システムさんが公開しているフォントサブセットメーカーを使用します。Windows版とMac版があるのが有り難いです。実際に使用する文字をテキストで指定する必要があるわけですが、今回は原稿Wordファイルからテキスト出力して使いました。本当は角ゴシックの部分、丸ゴシックの部分だけのテキストファイルを用意してやればさらに小さなサブセットが作れるはずですが、さすがに面倒なので断念。結果として出来上がったePubは700KB程度に。これならばiOSユーザの人にもさほど負担がない範囲かと。

なお、上記ページから辿れるWOFFコンバータでWOFF(Web Open Font Format)形式にしてやれば更に縮むっぽかったんですが、一部環境でアプリがクラッシュするなど問題が起きたので今回は見送りました。

埋め込み方法ですが、まずソースファイルのOEBPSフォルダの下、つまりTextやStylesフォルダと同階層にFontsフォルダを作り、ttfファイルを入れます。今回は、MTLc3m_sub.ttf、MTLmr3m_sub.ttfという名前にしました。

次にコンテンツファイルの目録であるcontent.opfファイルのmanifestタグの内側に下記2行を追加します。

<manifest>
(…各種xhtmlファイルなどが列挙されてる部分…)
  <item href="Fonts/MTLmr3m_sub.ttf" id="MTLmr3m_sub.ttf" media-type="application/x-font-ttf" />
  <item href="Fonts/MTLc3m_sub.ttf" id="MTLc3m_sub.ttf" media-type="application/x-font-ttf" />

</manifest>

そしてスタイルシートで、

@font-face {
    font-family: "MTLmr3m";
    font-weight: normal;
    font-style: normal;
    src: url("../Fonts/MTLmr3m_sub.ttf");
}
@font-face {
    font-family: "MTLc3m";
    font-weight: normal;
    font-style: normal;
    src: url("../Fonts/MTLc3m_sub.ttf");
}

と定義した後、任意のクラス等に

/* 角ゴシック */
.kaku {
    font-family: "ヒラギノ角ゴ ProN W3", "Hiragino Kaku Gothic ProN", "MTLc3m", "@MS ゴシック", "@MS Gothic", sans-serif;
}

/* 丸ゴシック */
.maru {
    font-family: "ヒラギノ丸ゴ W4" ,"Hiragino Maru Gothic ProN",  "MTLmr3m", "@MS ゴシック", "@MS Gothic", sans-serif;
}

等と指定します。なおこの例では最終的に丸ゴシックが使えないケースも想定してフォールバックフォントに角ゴシックを指定しています。iBooksだとヒラギノが優先的に使われ、それ以外では埋め込みのモトヤ、それもダメならMSゴシックか内蔵フォントという感じです。多くのリーダーだと、sans-serifでゴシック、serifで明朝の内蔵フォントになるようです。

■目次ファイル

Sigilが出力していたePub2.0ファイルセットを手作業でePub3.0化した際、目次ファイルであるtoc.ncxは使われないので削除してOKと書かれていたんですが、そうしてしまうとKindle PaperwhiteだったかSONY Readerだったか忘れましたが目次が使えなくなってしまいました。ので結局残してあります。目次ファイルが複数になってメンテナンス上は手間ですがまぁ仕方ないですね。

■様々なリーダー環境で確認

そんなこんなで、以下のプラットフォームで概ね良好なレンダリングが得られるものができました。

・iOS (iPad/iPhone/iPod touch)

Apple純正リーダーであるiBooksを使用。メール添付はSafariからのダウンロードでePubファイルをインストール可能。iOS6まではiMessage添付でもいけたんですがiOS7はダメになってるっぽい?配布ページにてヒラギノ丸ゴW4を別途インストールするようお願いをしています(アプリ内のフォント選択ポップアップで簡単に追加できます)。

・Mac OSX Merverick

こちらも最初からインストールされているiBooksで閲覧可能です。

・Mountain Lion以前のMac

上述のMurasakiが軽くてオススメですが、Adobe Digitai Editons辺りが大手企業ということで紹介しやすいかも知れません。

・Windows

同様に、Adobe Digital Editionsが無難でしょうか。

・Windows 8/RTストアアプリ

ePub対応を謳うアプリは山ほどありますが、残念ながら縦書きすら見られないようなものばかりでした。何か良いものがあれば是非ご紹介下さい。

・SONY Reader

手持ちのPRS-350(最新ファーム3.0.03.03190で縦書き、ルビ、縦中横、埋め込みフォント、目次ともに正常に機能しているようです。

・kobo

手持ちがないので未検証。楽天優勝セールで半額になってたので、kobo gloを注文しました。検証できたら追記します。確かkoboは段落毎に通し番号IDをつけないと目次や既読位置保存が使えないみたいな制約があったはずです。あと、拡張子をkepub.epubみたいな二重拡張子にしないといけないんでしたっけ?

・Android (Nexus7 2013でテスト)

これもePub対応リーダーは結構ありますが互換性は微妙でした。やはり商用リーダーアプリが優秀で、「紀伊國屋書店 Kinoppy for Android」と「ソニーの電子書籍 Reader™」で検証をしていました。ただ、サブセットフォント化したらKinoppyでの記号が崩れるようになってしまいました。また表紙画像がないePubはKinpppyでは真っ白な四角形になってしまうのもイケてないです。Readerは1ページ目のサムネイルを自動生成してくれます。ということで、今回の配布サイトではSONY Readerアプリを推奨することにしました。

なお、両者ともローカル保存したePubファイルを本棚に自動登録する機能があり、KinoppyではDownloadフォルダ、ReaderではReader->downloadsフォルダに保存した上で、アプリ内メニューから「追加コンテンツの検出」(Kinoppy)や「ファイルの取り込み」(Reader)すればOKです。

■Kindle用mobiに変換する

最後にKindle対応です。ePubを直接読むことはできないので、Amazon自身が配布しているKindleGenというツールを使って.mobi形式に変換します。ただし、残念なことに現状ではフォントの埋め込みは認識されないようです(Paperwhiteのみで検証)。先のCSSでかろうじて内蔵の角ゴシックにはなりましたが。シェアは大きいので一応対応したいところですが、やはり自炊用としてはKindleは微妙ですね。

どうせ埋め込んだフォントは使われず、貴重なKindle端末のストレージを無駄に占有するだけなので、ePub時点で埋め込みフォントを抜いたものを作ります。本当はCSSやopfも書き換えるべきなんですが、毎回作り分けるのは手間なので、内部エラー上等ってことにしてzipする時に除外するだけにしますw。区別のためにhoge_nofont.epubという名前にしておきます。

zip -0 -X ../hoge_nofont.epub mimetype
zip -r ../hoge_nofont.epub * -x mimetype *.ttf

KindleGenはコマンドラインツールですが、使い方は簡単でKindleGenとePubがあるフォルダで、

./kindlegen hoge_nofont.epub

などとするだけで、同じ場所にhoge_nofont.mobiが出来ると思います。警告が多少出ましたが、とりあえず問題なく読めるようなので良しとしましたw。

できたmobiを、USBでマウントしたKindleのDocumentsフォルダにコピーすればOKです。

 

まぁ、こうしてみると、「電子出版は紙代、インク代、輸送代がタダなんだから紙版より安くできないのはおかしい!」という読者視点の考えにやや無理があるのはわかりますねw。紙版からのコンバートは結構大変です。この上、挿絵などの画像データの扱いも含めて様々な環境での動作確認をしてなんてコストはバカにならないでしょう。今後、紙用の組み版もePubベースになる等して制作コストが一元化できるようになってくればまた違ってくるんでしょうけどねぇ。InDesignとかなら出力コマンド一発で出し分けられたりするのかしら?

Nexus7 (2013)買いました

Pocket

Kindle Fire HD 7”からの乗り換えとしてNexus 7 2013年モデルを買いました。もともと汎用タブレットとしてはiPad、iPad miniがあるのでAndroidタブレットはあまり必要と思っておらず、基本的に電子書籍読むのに手頃な7インチクラス端末が欲しくてKindle Fire HDだったわけですが、やはりKindle(端末ではなくコンテンツ)はコミックの画質が最低レベルで我慢ならなくなったのと、なんとなくタイミングとして新Fireを待ちきれなくてw。まぁ、iPad mini Retinaは9/10には発表されないだろうという賭けに出て。というか、やはり片手でもつのにiPad miniのフォームファクタはやはり無理があるんですよね。

基本、iPadやKindle Fireの新型を待つつもりでギリギリまで悩んだので予約はしてなかったんですが、ヨドバシで発売日夕方に行って普通に買えました。16GBモデルです。最近、タブレットは複数使い分けているので、あまり個々の容量はいらないですね。iPadも次は32GB位にするかも。

■ハード面

軽くて薄くて縦持ちで幅が狭いので片手でも取り回しは良いです。ただやはりiPad mini同様左右の縁が狭いので縦持ちの時の指の置き場には気を遣います。そこはFire HDの方が良かった点。Nexus7で片手の場合はガッとつかんで、音量ボタンでページめくりする使い方一択って感じ。裸だとWebなどの用途にはイマイチ。背面はラバーっぽいコートになっているので、例の吸盤リングは吸い付かず。iPad mini同様、ツルツルのケースが出たら買ってつけようかなと。

液晶の表示(色温度)は良好です。青すぎず、尿すぎず。Kindle Fire HDはやや色温度低めで動画には良かったんですが電子書籍読むにはちょっと黄色すぎたんですよね。

またスピーカーが上下についていて、横持ちした時はステレオになるのもGood。ただし側面部分についているので、手で覆ってしまうんですよね。スピーカーに関してもKindle Fire HDの方が一枚上手な印象。

カメラは使ってないしあまり使う予定もないのでスルーします。

初の非接触充電対応機ですがまだ充電器買ってません(忘れてた)。定番はPanasonicのヤツみたいですね。あと、docomoのワイヤレスチャージャー03が最安だし置き場所もとらず、シリコンカバーまでついててコスパ高い。このどっちかを買おうと思ってます。

■ソフト面

バージョンが4.3とはいえ、使ってみればおおむねフツーのAndroidで特筆すべきところはあまりないです。不満なくサクサク動くと思います。細かいUI上の不満点はありますが、それはNexus7固有の問題でもない気がするので、別途使いやすさ日記やFacebook辺りでツッコむとします。

■動画プレーヤーとして

1920×1200ともなればフルHDをドットバイドットで表示できてしまうわけですが、プレーヤーとしての操作性はフツーなのであんまり使わないかなという感じ。おやゆびでおみたいな片手でさくさく視聴できるプレーヤーがあれば別なんですが(ステマ)。ソニレコやnasneの録画コンテンツを再生できるレコプラも動きますが、TwonkeyBeamのDTCP-IPプラグインを買ってまでは必要ないかなぁという感じ。手持ちのmp4を入れてみましたが、このppiだとあんまフルHDスゲー!って感じはないかなぁ。綺麗は綺麗ですが感動はフツー。16GBしかないので、3,4本入れたら容量足りなくなったしw。

あと先に書いたように片手で左右端をもつとスピーカーを覆ってしまうので、真ん中ら辺を持つか、テーブルなどにおいて使う用ですね(置いて使うとますますフルHDの意味はなくなりますが…)。

■電子書籍端末として

メインの使途である電子書籍端末としては、一言で言うと、縦持ち単ページ読みなら最高。横持ち見開きだと(小さすぎて)ビミョー。自炊の講談社BOX(物語シリーズとか)みたいな縦二段組みの小説がオリジナルレイアウトのままかなり綺麗に読めます。久しぶりにPerfectViewerを使って設定を煮詰めてみたんですが、音量ボタンでページめくりでき、白黒反転やガンマ調整もできてかなり良いカンジになりました。若干ページ送りのタイムラグや、回転時の表示崩れ(一拍して直るけど)が気になるかなという程度。

山口さんのレビューで画質の評価が高かった紀伊國屋書店Kinoppyでも早速一冊コミックを買ってみましたが、確かにKindleとは比べものにならない画質で、これなら不満なく電子版買えるって感じ。まぁ、出版社次第なところもあるので全てのコミックがこうだという保証はないですが、当面コミックはKinoppyを基本に考えておきたいと思います。こちらのアプリもちゃんと音量ボタンでページめくりできるし、画面端タップは左右とも順送りにアサインできるなど、ツボを押さえた出来です(Kindleアプリは未だにこれができない)。またKinoppyアプリはページめくった後に一瞬送れて画質がキリッと締まるのが見えるので、アプリ側でもなんらかのシャープネスフィルタを都度かけてるみたいですね。

■リモートデスクトップ端末として

WUXGAの解像度を持つとなれば、同解像度(24インチモニタ相当)のPCの画面を映してみたくなるのが人情というものです(ですよねっ?)。早速iTap mobile RDPで試してみましたが、残念ながらAndroidのツールバー領域の分があるので、高さ1200はフルに使うことはできないようです。レスポンスは上々。

 

ということで、ファーストインプレですが、電子書籍端末としては確実にKindle Fire HDを凌駕していると感じました。特にKindle以外のストアも使いたい人には現状最強じゃないでしょうか。スピーカーや色温度の面などで動画に関してはKindle Fire HDの方が上をいく部分もあります。Kindleの新型が気になるところですね。

Kindleを寝転がって片手で使う為のハック

Pocket

連休の研究テーマは「Kindle Paperwhiteを仰向けに寝転がって片手で快適にダルダル読書をする」為のハック術。先日のレビューに書いたように、サードパーティのカバーの中には背面にハンドストラップがついているものもあるんですが、自分は基本的に持ち出さないので、無駄に嵩張ったり取り回しが悪くなるので敬遠。そもそも7,980円のガジェットにその半額前後するアクセサリをつけるというのが気持ち的に悔しいw。

実は事前にSimplismのリンググリップスタンドという吸盤でつけるタイプの保持用リングを買ってみたんですが、案の定ラバーコーティングのKindle Paperwhiteにはまともにくっつきませんでした(両面テープて貼り付けるプラ板も付属してますが、やはり7,980円でも直接貼り付けるのは躊躇われます)。

ということで本体に加工しない前提でDIYチャレンジ。まずはプロトタイプI(写真左)とプロトタイプII(写真右)。贅沢に“素材”を二重化することで強度と指への当たりの良さを実現しています。えぇぇと思うかも知れませんが、意外としっくり来ますw。

プロトタイプIIは結び目を作ることで更に指当たりを良くし、また操作性を向上させています。操作性というのは、例えば小指だけ手のひら方向に引っかけるようにテンションをかけることで、本体を手のひら側に押しつけて安定感を増す、といった微妙なコントロールができるといった話です。

kindle_hs1kindle_hs2

継続して使用する分には「なんかもうこれで充分じゃね?」って気もする予想以上の出来映えですが、

  • 長時間使うとやや鬱血するような気がしなくもない
  • 見た目的に電車とかで使うには気がひける
  • うっかり外れたり切れたりした時に痛い目見そう

などの課題が浮き彫りになってきました。

kindle_hs3それらを踏まえて翌日ホームセンターや手芸店を巡って使えそうなものを買い込んで来たのがこちら。

右側のDカンは若干幅が狭く外れやすいので除外。これ以上の幅のものも売ってたんですが、高さも増えたり曲線側のアールもついたりしてダメそげでした。

意外にしっくり来そうだったのが上のチェーン。どちらも1m当たり190円。上手く言ったら量産して売ろうかという量が確保できてしまいました。がしかし、帰宅してよくみると全ての切れ目が溶接(?)されており、ペンチなどではバラせないことが発覚。我が家のニッパーでも歯(刃)が立たなそうなので、今回の使用は見送り。実家に帰ったらチェーンカッターがあるのでチャレンジするかも。サイズ、形状的にかなりよさそうです。

結局今回使用したのは真ん中のプラ製の角カン。2つで100円。手芸店で購入。幅(内側)が30mmのもの。Kindle Paperwhiteは裏側が曲面になってるのでややフィットしないですが、一応ハマります(ハマり具体は動画にて)。これに平ゴム紐(幅2.5mm)を、(ミシンないし手縫いは面倒だし綺麗にならなそうなので)アイロン粘着シートで接着。コツがつかめず、というか粘着力が足りず試行錯誤しましたが、最終的に両側に粘着テープをつけるなどしてどうにかしっかりと接着できました。ただゴムの厚みが割と無視できないというか、ピッタリだと思っていた角カンのハマり具合がややキツ目に。まぁ、ゴムなんで引っ張って薄くなった状態でセットすると、かえって後で厚みが戻ってしっかり固定されてイイカンジといえなくもないですが。

完成したマークIがこちら↓!!

kindle_hs4

100円ショップで売っててもいいレベル(ドヤァ(原価もっとかかってるけど)。

とりつけてみた様子。風船ヨーヨーみたいにしても余裕です。プロトタイプと比べて指への当たりもソフトでナイス。ただプロトタイプIIの小指技が使えないのがちと惜しいかな。

■マークIIに向けての課題

上下センター位置にフック的なもので引っかけて左右どちらの手でもユニバーサルに使えるものを作って見たかったんですが、今日回った範囲では良いパーツが見付かりませんでした。金属板の曲げ加工とかすれば、内側に傷防止兼滑り止めのパッドをつけたりしていけそうな感じですが、次の課題としておきましょう。

あと、今回使用したプラ角カンだとiPad mini(+ハードケース付き)にはハマりませんでした。こちらにも合うようなパーツを探してマークI for iPad miniも作りたいなと思います。

Kindle Paperwhite向け自炊レシピ

Pocket

758×1024と高解像度化して、リフローをしないで余白除去だけをするレシピを再構築。

■ChainLPかPDFDietEasyか

PDFDietEasyというのが手軽で良いと聞いて試したんですが、どうも余白を指定してもKindle側の余白除去機能が効いてしまうらしく、画面一杯に文字が配置されてしまう状態を抜け出せませんでした。この現象(機能)はKindleシリーズで以前からあったことで、ChainLPやMeTilTran、eTilTranシリーズには四隅にグレーのドットを打つことでこれをキャンセルする機能が組み込まれています(実は本ブログでこのキャンセル技を詳解したのを見た方が作者にお願いして機能として実装してもらったという経緯が(ドヤァ)。やはり一日の長がありますね(ただ最新版でKindleに全画面表示を指示するタグを追加されるようになったので、もはやコーナーのドットは関係ないかも?)。てことで、今回はChainLPを活用することに。

■原稿の下準備

我が家の業務用スキャナfi-6130の自動傾き補正はイマイチなので、eTilTranを使って自動補正しています。お手持ちのスキャナ(+付属ソフト)の傾き補正に満足できない人は参考になさってください。ちと面倒ですが…

ChainLPも傾き補正をしてくれるんですが、なんか昔試した時にイマイチだった印象があるのと、我が家の場合はまずbREADERありきでどのみち下処理をするので、そこからの派生手順として。Kindleオンリーな人はChainLPだけで行けるかも。

またKindle Paperwhite用にはあまり文字を太らせない方がいいので、bREADER用にガンマ補正をする前段階で別途出力したものを使うようにしています。

■ChainLPの下準備

ChainLPはいくつかの外部ライブラリを使用します。基本的には配布サイトからリンクを辿ればOKです。この他、Kindle用の.mobi形式で出力するのに、Amazonが配布するKindleGenというコマンドラインツールが必要になります。Windows版をダウンロード、解凍し、.exeファイルをChainLPのフォルダに入れておきます。

次にChainLPを起動し、編集->詳細設定を開きます。重要なのは以下かと。タブ別に見て行きます。

・ファイル入力

kindlepw_rcp1

「事前リサイズ」をオフに。処理を高速化したり省メモリする為の設定ですが、なんか二回リサイズすると劣化が激しくなりそうなので、マシンパワーに余裕がある場合は精神生成上オフにしてます。体感では処理時間もかわない印象。出力サイズがOFFの方が5%ほど大きくなるのも良い兆候と捉えていますw。

・画像

kindlepw_rcp2

画像形式をJPEGにしておきます。特に弄った覚えはないんですがGIFになっていました。PDF出力しようとすると「すげーデカくなるよ?」って警告が出たので直しました。今回の.mobi形式出力に影響するかはわかりませんが念のため。

・ファイル出力

kindlepw_rcp3

冒頭に書いたKindle用のグレードットを四隅に打つ設定です。これも今となっては必要か微妙ですが念のため。

・ページ補正

kindlepw_rcp4

ノンブルとはページ番号や章タイトルのことです。小説の場合は左右上にあることが多いですが、ChainLPではこれを画面下などに移動させることができ、その指定です。プレビューで結果が確認できるのでお好みで。ページ番号いらないという場合はチェックをOFFにしておけばOKです。

「挿絵を判断された~」は、文字通り挿絵ページの自動認識指設定です。挿絵ページと本文ページでは余白除去やガンマ補正などのパラメーターを別々にした方が綺麗なんですが、その区別をある程度自動でしてくれます。が、これが完璧ではないので、次節で補完します。

・トリミング&余白

詳細設定を抜け、改めて編集メニューから「トリミング&余白」を選んで開きます。本来、無駄な余白をカットして少ない解像度になるべく大きく綺麗に文字を表示させる為の補正ですが、個人的には全く余白がないというのも落ち着かないので、ここで上下に若干の余白をつけるよう設定します。数値はお好みで(「更新」を押すとプレビューに反映されます)。上側は縁の厚みによる影が落ちるので下側よりは多めにするといいかなと思います。

kindlepw_rcp5

 

さて、共通設定は終わりで、いよいよ目的の原稿画像が入ったフォルダをChainLPにドロップします。

■原稿毎の処理

文字ページと同じ基準で補正をすると挿絵が真っ黒になってしまう場合があるので、左の一覧で挿絵のページのみチェックボックスをONにしておきます。先の設定をONにしておけば、ある程度自動判別してくれるはずなんですが、時として全くONにならないことが(最新版のバグ?)。σ(^^)はExploreでサムネイル一覧表示にしておいて、見比べながらチェックをつけています。kindlepw_rcp6

出力形式はMobi。画質的にはPDFの方がいいみたいですが、ページめくり方向が左綴じ固定になってしまうので妥協しています。画質優先の人はPDFと出し比べてみて下さい。

サイズはKindle Paperwhiteの固定画素数である758と1024を指定。

次に、ノンブル位置を指定します。先ほどの設定はノンブルの移動先、こちらは元の位置を指定します。左右ページでそれぞれ外側に別れて配置されてるものがほとんどだと思いますが、その場合は「左右上」を指定すればOKです。プレビューで意図通りの結果になっているか確認して下さい。

本文ボールド化をONにすると文字が濃くなりますが同時にやや太ってつぶれ気味になります。原稿の状態にもよりますがKindle Paperwhiteでは必要ないかなと思います。ガンマ補正も同様。というか最新版からなぜかグレーアウトして使えなくなりました。自動レベルはON/OFFできるのでお好みで。ヒストグラムでも濃さが調整できますが、eTilTran等のようにページ毎の指定ではなく、本文ページと挿絵ページの2種類の設定しかありません。他の同種のページにも反映されてしまうので注意が必要です。

最後にタイトル、著者を指定して「出力」ボタンを押します。

■mobiファイルのダイエット

一応上記で完了で、Kindleに転送すれば読めるんですが、もうあとひと手間かけるとファイルサイズを半分にできます。どうも(ChainLPがmobi出力に使う)KindleGenが変換前の画像もファイルに含めてしまうようで、以下の方法でそれを取り除くことができます。無駄なファイルを消しているだけなので画質が落ちたりということはないはずです。

ただ準備はちとめんどくさいです。コマンドプロンプト操作に慣れてないと辛いかも知れません。

KindleStrip.pyというツールなのですが、Pythonというスクリプト言語でプログラムされており、Windowsの場合はまずそちらをインストールしなければなりません。こちらからダウンロードします。32bitの人は「Windows Installer」、64bitの人は「Windows X86-64 Installer」でいいでしょう。自分のOSがどちらかわからない人は前者でOKです。ダウンロードしてダブルクリックすれば普通にインストーラーが起動するので、そのまま最後までインストールします。

KindleStrip自体は上記ページから、.app(Mac用)ではなく.pyという拡張子の小さい方をダウンロードしておきます。「パスってなんぞ?」という人はとりあえずデスクトップにmobiファイルとKindleStrip.pyの両方を置き、以下に手順に従って下さい。

  1. コマンドプロンプトを起動する
  2. 「C:\Users\(ユーザ名)>」と出ているはずなので、「cd Desktop」と入力してリターン
  3. 続いて「\Python27\python.exe kindlestrip.py “元ファイル名).mobi” “ダイエット後ファイル名.mobi”」と入力してリターン

数行のメッセージの中に「done」という言葉が入っていれば成功です。同じくデスクトップに「ダイエット後ファイル名.mobi」の名前でサイズが半分になったファイルができているはずです。

3.のPython27の27はインストールしたPythonのバージョンによって違うかも知れません。またファイル名が日本語(2バイト文字)を含む場合は、半角のダブルクオーツ(””)で囲ってやらないとダメかも知れません。それでも上手くいかない時は一旦ファイル名を半角英数だけにしてからやるといいかも。

結局、Kindle Paperwhiteも買ったった

Pocket

iPad miniを買ったしイラネと思いつつも、微妙に値下がりして、この値段なら買っても良かったなー、と思いはじめ、さりとて今更注文しても納期が1月とかなのでスルーを決め込んでたKindle Paperwhiteですが、発売日の昨日、普通にビックカメラに売ってたので買ってしまいました。家電量販店ではヨドバシ、ヤマダはAmazon憎しで取り扱わず、Amazonに出店していて共存を目指すビックカメラや、ケーズ、TSUTAYA辺りは扱うらしいですね。

■ハード面

サイズ、解像度、バックライトなど電子ペーパー的にほぼ同スペックのkobo gloと比べ、本体外寸はひとまわり大きい本機ですが、やはりサービスが全く別モノなので比べても仕方ないでしょう。

kobo gloは店頭で少し触った程度ですが、あちらのバックライトは輝度を上げるとインク色まで青っぽくなって、大昔のΣBookみたいな安っぽさがありました。それに比べると本機のバックライトは最大輝度としてはkobo gloに劣るものの、最大照度近辺でも墨色部分に不自然な青白さがあまり感じられない印象。暗いところでの補助というより、紙色をより白く見せるためのバックライトなのかなと。ただやはり海外発売時に言われていてムラはあるし、白部分に青さは出るので、点けなくて済むなら点けずにいた方がいいなぁという感じ。特に真正面から見た時の違和感が大きい。少し下方向からみるとむしろ綺麗なんですが、

レスポンスはまぁ電子ペーパーとしては納得のレベルかな。自炊コンテンツの場合、開いた最初の数秒は反応が詰まるのもお約束。iPad等に慣れていると多少イラっとしますが、普通に読み始めると(先読みが進むと)ほぼ問題ないページめくり速度になります。

あと、KindleDXやSONY Readerで気になっていたUSB経由でコピーする時の書き込みの遅さも随分解消されたなと思いました。前二機種はどんだけ安いフラッシュメモリだよって位書き込み遅かったです。

背面はラバーコートですが、滑りにくいかっていうとそこまででもなく、寝転がって片手保持するなら背面にハンドストラップ(?)のついたケースが欲しくなります。このニーズは結構把握されてるようで、BUFFALOはじめいくつかのブランドのケースでは既に対応済みです。個人的にはカバーいらないのでストラップだけ追加できるようなアクセサリが欲しいなぁとも思いますが。

■操作性

惜しいのはページめくりのタップ操作方式です。過去に何度も書いてますが、この手の端末では持ち手を頻繁にスイッチする為、左右どちらの手で持っても親指で順送りできることが重要です。逆送りなんて頻度でいえばたいしたことないので、スワイプとかで充分なんですが、どうもこの手の端末メーカーは順送りと逆送りの操作の対称性にこだわりたいようで。せめてiBooksアプリや他の多くのリーダーアプリのようにカスタマイズできるといいんですが。

Kindle(写真左)の場合、ヘルプ画像にあるように右寄りの狭いエリアが逆送りで、残りは順送りというタップ反応エリアを非対称にする措置をとっています(もちろん本の綴じ方向によっては反転します)。なので一応右手で持っても親指をちょっと伸ばせば順送りできるっちゃできるんですが、やはり地味に負担が大きいというか、読書に熱中していると指の伸ばし方が足りずに逆送りになってしまってイラッ☆とします。これに関して設定は一切できません。また裸で片手持ちする場合、画面上の枠を人差し指と中指で挟むようにして持つことが多いんですが、この状態で親指でタップすると上部のツールバー呼び出しゾーンが反応してしまうこともしばしば。

参考までにkobo gloの設定画面も載せておきます(写真右)。デフォルトは左右の一定ゾーン、設定で真ん中部分まで使うことができますが、両方順送りに指定することはやはりできません。このプレビューで見る限り、逆送りゾーンも結構太いみたいです。

kindlekoboglo

この辺りの割り切り、シンプルさがiOS等を爆発的に普及させた大事な観点で、日本メーカーが苦手とする部分でもあるんですが、当のApple製リーダーiBooksですらこの点は認識してカスタマイズ可能にしているんですよと言いたい。

脱獄したらこの辺りの境界座標をいじれるよ、っていうなら迷い無く脱獄したいレベルです。

■画質

KindleDXを除く多くの電子書籍端末は長らく600×800というのが主流でしたが、kobo glo共々ついに758×1024と高解像度されました。さすがにKindleの小説コンテンツはその恩恵を感じられます。一方Kindleコミックはまだまだ微妙。文字はかろうじて読めますが、トーンがつぶれてモアレが発生しまくり。iPad miniでも指摘しましたが、それよりも気になります。例えば無地のシャツを着ているはずのキャラが妙な柄物を着てることに翻案されてるレベル。服ならまだいいですが、髪に模様とかおかしすぎますw。もう少しインテリジェントなスケーリングアルゴリズムを採用するには処理能力が不足なんですかねぇ。個人的にはこれでコミックを読むことはない気がします。

自炊(小説)に関しては、この解像度変更でMeTiltranを使ったリフロー処理をしなくても、ChainLPの余白カットだけで実用になる域になったのが大きいと思います。特に一段組の文庫本なら充分です。画質的にはPDFが綺麗らしいんですが、なぜかページめくり方向が左綴じ固定になってしまう仕様で、現状はやや文字が太るもののmobi形式を使うのが無難かなという気がしています。自炊レシピについては別エントリにて。

■その他

KindleDXの頃と違い、充電器は付属していません。まぁいまやスマートフォン用にUSB5V充電器やmicroUSBケーブルなんて家に転がってる人が多いので妥当なところでしょう。ただ付属のmicroUSBケーブルはKindleDXに付属のものと似ている手触り。DXのものは1,2年で皮膜が硬化してボロボロに割れて来たので、今回もイヤーな予感しまくりです。

とにかく傾き補正を重視した自炊レシピメモ

Pocket

bREADERで快適に小説を読む為の自炊研究の続き。前の記事では、ノンブル領域を目安に素早く傾きがヒドいページを見つける方法を模索しましたが、これ自体が傾き補正精度を上げる訳ではありません。今回は全く別のアプローチで傾きを軽減するレシピについてです。

実はこれを見つけたのは偶然というか怪我の功名というか、還付金でもっと傾き補正がイケてるスキャナに買い換えようかと情報収集をしていて、(他のスキャナの話ですが)「傾き補正をオフにした方が傾かない」という書き込みを見つけたことがきっかけでした。多くのスキャナの傾き補正機能はeTilTranのような文字や罫線を認識しているのではなく、ページの末端を使っているらしいのです。で、自炊など断裁機で背表紙を裁ち落とした辺は傾いていることも多いので、これがかえって傾きを助長させてしまう(本来比較的まっすぐに取り込めているのに、この傾いたページ境界を使ってかえって傾いて補正されてしまう)という訳です。特に我が家の場合、糊残りでくっついてるページで重送されにくくする為と、スキャン速度を上げる為に、文庫本などは横向きにセットします。糊が残っている可能性がある断裁した側を上(後ろ)に向けるので、特に影響を受けてしまうんじゃないかと(ページ後端で識別するものが多いらしい)。

ということで、手持ちスキャナ(fi-6130)の付属ソフトの傾き補正をむしろオフにしたら他のモードにしてみたらマシになるんじゃね?ってことで実験を始めました。同スキャナの付属ソフトScandAll PROでは、「自動傾き/サイズ検出」という設定項目に「無効」、「後端検出」、「自動用紙サイズ検出」、「黒背景」という選択肢があります。「よしこの4モードを全て試して傾き方に違いが出るか試すぜ」となったんですが、そのうちの最後、「黒背景」というのが思わぬ結果をもたらしてくれたのです。

1. 黒枠つきでスキャンする

0021

実際に「黒背景」モードでスキャンするとこんな画像が吐き出されます。このスキャナがスキャンできるA4サイズに対し、紙がかかっていなかった部分が黒く塗りつぶされている訳です。一見すると使い物にならない訳ですが、ものは試しにとeTilTranに食わせてみるとびっくり!かなりの精度で傾きが補正されています。それもそのはず、下の写真はeTilTranの内部演算プレビューを表示したところですが、中の文面には目もくれず、紙面と黒枠の境界部分の上下辺を基準に補正してくれてます。つまり断裁の影響を受けていない2辺ということですね。

image

見かけ上、解像度が落ちてるようですがそんなこともなく、単に全体のピクセル数が大きいので縮小されて見えるだけです。

つまり、この画像から黒枠部分をトリミングできればほぼ理想の傾き補正済み画像が得られるという訳です!

2. 黒枠部分を裁ち落とす

おそらくこのような画像を読み込んだ場合、全てのページが「漫画」種別で認識され、基準テクスト領域が全体を囲い、ノンブル領域は未指定になってると思います。まずこの基準テクスト領域を紙面相当部分に指定しなおしてやります。

「領域設定」ウインドウで偶数ページ、奇数ページそれぞれ値を修正していきます。前にも書きましたがeTilTranの領域設定はマウスで範囲指定して、とかできないのでちと面倒ですが、まずWidthとHeight値を「黒枠なしでスキャンした場合に出てくるサイズ」を目安に指定すると手っ取り早いです。300x300dpiでスキャンした文庫本の場合、1180×1760位になります。少し小さめ位にしておくと後の調整が楽です。偶数ページと奇数ページでは多少ズレが出るので片方に合わせたあとで4つの数値を書き写し、X,Yを修正してやります。またページを重ねるうちに段々ズレてくるので、最初の方と最後の方で確認しておきます。枠を小さめにしてどこでチェックしても黒枠が入らないようにすればOKです。

今回の例では、

偶数ページ X:0239 Y:0187 W:1175 H:1760

偶数ページ X:0193 Y:0182 W:1175 H:1760

となりました。基準ノンブル領域は設定しなくていいです。

次に前回も使用した「自動領域補正」を使います(失敗してもいいよう適宜プロジェクトを保存しつつ作業して下さい)。「トリミング範囲を基準領域から自動計算する」にチェック。余白指定はお好みで(指定したピクセル分の余白が各4辺に足されるようです)。中段は「基準テクスト領域に、テクスト領域のみを合わせる」を選択(ここの選択肢の違いはよくわかってませんが、まぁノンブルは指定してないのでノンブルを使わないのがいいだろう、位の理解w)。

imageすると今回の例では偶数ページだけが少し右へズレてトリミングされてしまいました。とはいってもこの段階で実際にトリミングが完了している訳ではないので補正が可能です。まず右サイドバーの「テキスト補正」欄を見ながらカーソルキーでプレビューを動かして、いい感じに赤枠に紙面が収まる位置を見つけます。今回はX(水平)方向に-25でOKそうです。この数字だけ記憶し、一旦補正を0に戻します。

次の同じだけの補正を全偶数ページにだけ一括適用させます。「ツール」->「一括補正」を開き、写真のような感じで指定し「適用」をクリックすれば、全偶数ページが25左に移動してピッタリ赤枠内に収まってくれます。部分ごとにパラーメーターを変えて適用することもできるので上手く使いこなして下さい。

image

3. 後処理

σ(^^)の場合、この後はヒストグラムを調整して文字を濃くするんですが、ひとつ困ったことがあります。全てのページが一律で「漫画」に分類されてしまっているので、挿絵のページを除外してヒストグラム変更する、といったことができません。

仕方ないので手作業で分類しなおす訳ですが、その際は、Explorerでサムネイル一覧表示にしてやれば挿絵ページをすぐ見分けられるので、それと見比べながら作業するのが良いかと思われます。

 

eTilTranの作者さんは最近はChainLPばかりメンテされてeTilTranはあまり手を掛けて下さってないですが、個人的にはこれが一番便利で使い出があると思います。なんとかマウスで領域指定できるようになってくれるとさらに神なんですけどねぇ。

2012.04.19追記:コミックの場合、「原稿外枠しきい値」を調整する

そもそもeTilTranにはこうした黒枠がついた画像を識別し分離する機能がついていました。設定->原稿外枠というカテゴリのパラメーターで、「原稿外枠しきい値」と「原稿外枠識別」の2つです。後者は単なるON/OFFなのでまぁONにしてきます。で、前者は文字通り、外枠として認識する基準値を指定します。基準の決め方は上記公式サイトの説明にあるように、「モノクロ化閾値上限」をかえつつ、内部演算プレビューで「二値画像」を選択した状態で、綺麗に中身が真っ白になり、外枠だけが黒くなる状態を探します。その数値をこの「原稿外枠しきい値」に指定して、再読込すればOKです。説明には50~80とありましたが、カラーページなどはかなり低くしないと上手く分離できませんでした。まぁ、白黒のページで基準領域が決まったら、あとは「原稿外枠識別」をOFFにしてカラーページだけ再読込してやればヨサゲ(ページ毎の再読込は、左サイドバーのリストを右クリックすればメニューがあります)。