カテゴリー: 電子書籍自炊／リーダー

前エントリで最近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にしてた。やはり色々暴露されすぎてイヤになったとｗ。電子版ならではの楽しみを付加したい気持ちはわかるんですが、やはりまだシーズ先行感が否めないですね。でもkoboのバッジはちょっと楽しそうかも。

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

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

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

■ハード面

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

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

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

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

■ソフト面

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

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

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

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

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

■自炊レシピメモ

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

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

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

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

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

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

■縦書きにする

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

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

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

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

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

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

段落毎などにマージンをいれたい場合、margin-right（段落の手前）、margin-left（段落の後）を使います。Kindle出版ガイドに、「emではなく%で表示しないと、文字を拡大した時に無駄に行間が空いちゃうよ」と書かれており、試しに%に書き換えてみたんですが、iBooksでヒドいことになり戻しました。どうも基準となる100%の幅として画面縦のピクセルを使っちゃうようです。ウインドウの縦の長さを変えると、横にマージンが広がる、という状態にｗ。縦書き対応が不十分なんですかね。あるいは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;
}

■フォントを埋め込む

これが一番苦労しました。本文に丸ゴシックがあるのですが、多くのリーダーは明朝とゴシックが１書体ずつ入っているのみ。また手持ちの初代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 Gothic", sans-serif;
}

/* 丸ゴシック */
.maru {
    font-family: "ヒラギノ丸ゴ W4" ,"Hiragino Maru Gothic ProN",  "MTLmr3m", "@ＭＳ ゴシック", "@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は１ページ目のサムネイルを自動生成してくれます。ということで、今回の配布サイトでは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が出来ると思います。警告が多少出ましたが、とりあえず問題なく読めるようなので良しとしましたｗ。

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

・ファイル入力

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

・画像

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

・ファイル出力

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

・ページ補正

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

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

・トリミング＆余白

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

 

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

■原稿毎の処理

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

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

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

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

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

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

■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のバージョンによって違うかも知れません。またファイル名が日本語（２バイト文字）を含む場合は、半角のダブルクオーツ（””）で囲ってやらないとダメかも知れません。それでも上手くいかない時は一旦ファイル名を半角英数だけにしてからやるといいかも。