「EPUB3::かんたん電子書籍作成」 http://books.doncha.net/epub/ では、扉ページをつけることができる。

短編集の場合、本のタイトルではなく各々の短編タイトルで扉ページ（※ページの中で左右中央配置の縦書きのタイトルだけの一ページ）が欲しかった。

用意するもの本文テキストと表紙画像の二つ。

表紙画像は、KDPの登録の時に使う＝AmazonのKindleストアの本の詳細ページに表示されるカバー画像（縦横比1.6＝1920x1200 300dpi jpg）をそのまま流用した（デバイスの縦横比より縦長なので左右にアキができるけど）

本文テキスト。

（（扉タイトル））猫神の場所 → カッコカッコ扉タイトルカッコカッコ が扉

（小見出し）１ 遠い場所に → カッコ小見出しカッコ が小見出し

（ちなみにオレンジのハイライト部分はルビ指定）

「かんたん電子書籍作成」のフォームにタイトル・著者名を入力して、扉や小見出しの指定が書かれた本文テキストと表紙画像をアップロードしてEPUB3をダウンロード。

上記EPUB3をKDPで登録（「猫神リスペクト」（日野裕太郎・てぃるよし））したものを kindle Paperwhite とプレビューワーでのスクリーンショットが以下。

表紙画像。

目次。扉ページも目次に（階層表現）

扉ページ。（扉のタイトルの他に、惹き文句を入れてあります。やりかたはこの記事の最後に）

扉ページ部分のスタイルシート

body.tobira-page{
    margin:0； padding:0；
    -epub-writing-mode:horizontal-tb；
    writing-mode:horizontal-tb；
}
div.tobira-text{
    margin-left:auto；
    margin-right:auto；
    margin-top:1em；
    -epub-writing-mode:vertical-rl；
    writing-mode:vertical-rl；
    height:100%；
}
div.tobira-text h1{
    font-size:1.1em；
}

・扉ページだけ、ページ全体の文字送り方向を水平（横）に指定する。

　horizontal-tb

・タイトルを入れたブロック要素をセンタリングする。

　margin-left:auto margin-right:auto

・タイトルを入れたブロック要素の文字送り方向を垂直（縦）にする。

　vertical-rl

本文小見出し。

目次や改ページなど意図通りにできている。

で、扉ページに惹き文句をつける方法。というか、EPUB3をバラして直接HTMLを編集する方法のひとつ。

まずは、ダウンロードしたEPUB3を解凍して中身を確認。

text/contents001.xhtml 「contents ＋ 連番 ＋ .xhtml」というファイルが本文テキストが入っているHTMLファイル。この中から扉ページをピックアップして編集する（目次の「表紙」の次から連番で、例えば「２　猫神になること」は contents003.xhtml になる）

できればテキストエディタやdreamweaverのようなHTMLエディタを使う（ワードなどのアプリを使って編集した場合は、EPUBチェックを使ってエラーがでないことを確認。いろいろ意図しないところが書き換える可能性があるので）

かんたん電子書籍が作るHTMLは、この扉ページ contents001.xhtml （あ。sectionなどのタグがあった方がいいかもしれない。けど、後で考えます）

contents001.xhtml に、惹き文句として以下の赤い部分を追加（フォントのサイズをデフォルトの80%にして、４文字分下げている）

EPUB3はHTMLをパッケージしたものなので、HTMLを直接編集すれば意図通りに近づけることができる。ただ、タグを埋め込んだ原稿と、生原稿で違いが出てくると管理が面倒くさくなるので注意が必要。

[2014/01/29 13:02:31] 追記。

「かんたんEPUB3作成ローカル版」 で作ると中扉はもっと簡単！

「EPUB3::かんたん電子書籍作成」 http://books.doncha.net/epub/ に、挿絵をいれるためのひな形を作れるようにしてみた。

挿絵、イラストのアップロードとなるとサーバーの負荷など考えることが多いので、ダミーの挿絵を生成して、EPUB3ファイルをダウンロード後イメージを差し替えてもらうやり方。

テキストデータに（挿絵入る）と書いたところが挿絵ページとなる。

カッコ挿絵入るカッコ

という書き方。一ページ全画面の挿絵（といっても、リフロー型EPUB3の挿絵は天地左右にマージン（余白）が出る）で、挿絵の前後で改ページとなる。

ダウンロードしたEPUB3ファイルを解凍したものが以下。

「かんたん電子書籍作成」では、小見出し単位でファイルを分割している。挿絵や扉絵なども分割してひとつのファイルにして出力する。

（改ページにもなるし、またデバイスによって一度に読み込めるファイルサイズの上限が厳しいという話を以前ちらっと聞いたこともあったので）

・xhtmlファイルの名前の連番は、本文、挿絵関係なく先頭から順番。

・画像は該当するxhtmlファイルと同じ番号のjpeg画像（72dpi 600x800）

扉も挿絵も以下のような画像を作ってEPUB3ファイルに梱包している。これを用意した扉絵や挿絵と差し替える。

・変更したい画像と同じファイル名で画像を作る（300dpiが推奨される）

・images フォルダに入れる（上書きする）

例では、挿絵としては１番目だけど、ファイルの順番としては３番目なので「挿絵003」になります。

ということで、挿絵をつけるには

「ダミーで作る画像と同じ名前の挿絵（contentsNNN.jpg）を用意して上書きするだけ」

です。

EPUB3ファイルの実体はzipファイルなので、解凍に関しては、拡張子.epub を .zip に書き換えて解凍すればOKです。

解凍してイラストを入れ替えたものを再度EPUB3に圧縮梱包するには少し約束事があるので

EPUB3ファイルの圧縮や梱包についてはこちら → 「EPUB3のzipに梱包圧縮する」

macでEPUB3ファイルを解凍するにはこちら→ 「macOSで EPUB3解凍 .zip と.cpgz」

[02/27 12:02:11] 追記。kindle KDPのガイドラインを見ると、リフロー型に入れる画像については上限が127KBという話でそれ以上はKDP側で登録時に圧縮するらしく、その際に画質は劣化するとのこと。…ちょっと厳しい制限かなあ。

[03/05 22:01:54] 追記。

挿絵をつける具体例・実践編 → 「挿絵の多いくまっこ本『ほしのこ』作成メモ

[2014/01/29 12:58:42] 追記。

「かんたんEPUB3作成ローカル版」 で作ると画像指定はもっと簡単！

この雑記帖スクリプトでは、公式APIが使いにくい・デザインが合わないブログパーツなどに関しては、HTMLから直接取得している。

twitterの「その他」→「ツイートをサイトに埋め込む」

この機能は便利なのに、表示・デザインに自由度がなくて、サイトに埋め込むと

このありさま。どっちが本文でどっちが引用（ツイート）なのかわからない我が侭な自己主張。ユーザビリティ、デザイン的にこれはない。

twitterとしては、表示をコントロール下において広告などで収益を視野に入れて展開したい、んだろうけど。サイトはこちらのもの。大きな顔をされては困る。

Amazon AWS の API でレビューが取得できなくなっていた（もう２年も前の話。今さら気づくのんきな父さん）

商品情報に含まれているのは、ユーザーレビューがあるかないか（true false）ユーザーレビューページのURL（24時間の期限付き）。このURLをインラインフレームで埋め込んでね、ということらしい。インラインフレーム表示させると、サイトの統一感を壊してしまって、楽天のチラシのような見た目になってしまう。

Amazonとしては、レビューの品質を上げるためにレビューをコントロール下において、レビューの精査・削除などしていきたいんだろう。

しかたないので、twitterもAmazonも公式APIを使わずに、HTMLを解析して取得、スタイルシートなど調整して、サイトにおさめるようにした（スクリプトのソースはちょっと内緒。HTMLのどこを見てるかあまりおおっぴらにするのは良くない＝ルール違反かなあ）

見やすいサイト、使いやすいサイトは、サイトに掲載される情報の分類がきちんとわかりやすくレイアウトデザインされていて、動線も明確でリンクをクリックしたら何が起こるのかわかりやすくなっている。

アートは感性・デザインは理屈。サイトもデザインと同じで、どうしてこの位置にこのブロックがあるのか、なぜ動線はこっちに向けてるのかなどなど、いちいち説明がなければならない。

情報設計＝インフォメーションアーキテクチャ＝IA というらしい。初めて聞いたときは、また妙な、きっとくだらないカタカナ言葉でひとを騙そうとしやがって、だったんだけど本を読んでみると、IAに関してはWEBに関わるひとにとって必須。

EPUB3::かんたん電子書籍作成 http://books.doncha.net/epub/ では、テキストデータにルビや縦中横のHTMLタグを自動で振るためのオプションを用意してある（※ ページ中ほどにある [スクリーンショット、ルビや縦中横タグを挿入するにはこちら] のリンク）

そのための perl の正規表現メモ。

縦中横。

半角の、「!?」「!!」「?!」と、連続するアルファベット、連続する数字に span タグで縦中横のクラス tcy をつける。

マジか!? → マジか<span class="tcy">!?</span>
体重45kg → 体重<span class="tcy">45</span><span class="tcy">kg</span>
s/(\!\!|\!\?|\?\!|[a-zA-Z]+|[0-9]+)/<span class="tcy">$1<\/span>/g

ルビ。

「漢字(るび) 」と漢字に続いて半角のカッコに囲まれたひらがな・カタカナをルビとして ruby rt タグをつける。

※ WORDのルビつき文書をテキストで出力すると半角カッコの中にルビが入る

般若心経(はんにゃしんぎょう) → <ruby>般若心経<rt>はんにゃしんぎょう</rt></ruby>
超新星(スーパーノヴァ) → <ruby>超新星<rt>スーパーノヴァ</rt></ruby>
s!([\p{InCJKUnifiedIdeographs}]+\x{3005}?)\(([\p{InHiragana}\p{InKatakana}]+)\)!<ruby>$1<rt>$2</rt></ruby>!g

\x{3005} は「々」

縦中横のタグはけっこうよく使う正規表現なのですんなり。でもルビのための漢字判定がちょっとわからずグーグル様。perlは5.8以降、ユニコードによる正規表現が使えるようになって、文字クラスを下記のように指定することができる。

\p{InBasicLatin}   半角英数字と半角記号
\p{InHiragana}     平仮名
\p{InKatakana}     カタカナ
\p{InCJKUnifiedIdeographs}   漢字
\p{InCJKSymbolsAndPunctuation}   全角記号
\p{InHalfwidthAndFullwidthForms} 半角カナなど

ルビもこれを使って正規表現。でも、スクリプトでは、どこからルビなのか判断できない。東京都千代田区（ちよだく）と書いてあったら、「千代田区」ではなく「東京都千代田区」に「ちよだく」のルビがつく。「千代田区」にルビですよということで「東京都［#ルビ］千代田区(千代田区)」などとテキストにマークアップする必要がある。

「EPUB3::かんたん電子書籍作成」 のコンセプトは

「何も考えずにテキストを放り込んだら、それっぽい電子書籍ができる」

面倒っぽく感じる・小難しそうなことは極力排除したいので、Wikiやはてなで使われるような独自記法・方言マークアップは却下とした。

レイアウトデザインを作り込みたいということであれば（字下げや文字方向一部変更など）EPUB3ファイルを解凍して直接xhtmlに対してタグをつけて、CSSを作れば可能。「かんたん電子書籍作成」で作るHTMLとCSSは、こんなでいいのかというぐらい手抜きレベルに単純なHTMLなので、編集加工がしやすい元素材でもある。

HTMLタグのついたテキストデータで小説原稿などを保存管理するのは面倒なので、元原稿はプレーンな状態にしておきたい。間違えて元データを消してしまって、HTMLタグのついたデータしか残ってない！という場合に。

テキストデータからHTMLタグを除去する正規表現

s!<rt>[^<]+</rt>!!g ルビ除去
s!<[^>]+>!!g HTMLタグ除去

「今さら」以前からあちこちで言われていたように「電子書籍」という名前がまずかった。

「電子書籍」は「書籍」じゃなくて、既存の本を電子データコンテンツに移植したなにか。

売るためにパッケージして名前をつけなきゃいけないのでebookと、電子書籍と名付けられて呪われてしまった。名前をつける行為は昔から呪術的だしねえ（てなことを以前ちらっとだけ書いた）

読む側にしてみると実体として本がまだまだ魅力的だろう。

Kindleストアで電子書籍は売れる？ (2012/10/31)

「本を手に取って、開いてめくる。文字を読む、文章を読む」体験は、味覚以外のすべての感覚を使った豊かなもので、電子書籍では味わえない。
新しい本・古い本で匂いは違うし、本を読んでいて読み進むにつれて右ページ側左ページ側で重さが変わるし、ハードカバーと文庫ではページを捲る音が違う。

上記は、どちらかというと読み手側視点から。kindleのKDPのおかげで電子書籍を作って並べるのに、ハードルがぐぐぐぐぐっと下がって、誰でも簡単にできるようになった…のはいいけど、今度は書き手側に広がる電子「書籍」という名前の呪縛。

紙印刷は誰がどこで見ても同じものが見える。それと同じことを電子書籍に要求するのは筋違い・無い物ねだり（紙のレイアウトデザインを忠実に再現するPDFでさえ、パソコンで見ると、ディスプレイの色調整次第で別モノの印象を与えることもある）

電子書籍は紙の本、書籍というよりもWEBに近いシロモノだ。

「自分のパソコンのディスプレイ上で」デザインやレイアウト、文字の装飾やフォントの選択など細かくこだわって作り上げて販売しても「他人のパソコンのディスプレイ上ではどう見えるか決めることはできない」

パッケージされたデータを解釈して表現するのはユーザー側にあるアプリやデバイス。画面での表示サイズや色などユーザーが接するところはユーザーがアプリを通じて自由に自分の都合で変更できる。書き手が自分の目の前で完成させた形をそのまま伝えるのは難しい。

インターネットの「ホームページ」、昔は「推奨ブラウザはFireFoxで、画面は1024x768以上、フォントサイズは12pxでご覧ください」なんてページがあったのと同じことかもしれない（作り手の環境をユーザーに押しつけちゃいけません。というのがユーザビリティというヤツ）

みんなが同じものを見るのが前提の紙印刷とは真逆（反射光と透過光ですね）

kindleの個人作家のツイート「販売停止にされた！けしからん！！」と怒る気持もわかるけど、電子書籍に対する誤解が元になってないか。

フォントをはじめとする表示まわりを決めウチで作り込んでないか確認するのが先。ファイルの作り方が間違ってないかチェックするためのツールはあるし、kindleは丁寧なガイドライン（PDF）が「ヘルプ」ページにあるので問題点を洗い出してまず調べる。

その上で「意図通りのもの」にすることを考える。

電子書籍は書籍とは別モノ。