EPUBファイルは、複数のファイルがひとまとまりになったものです。rune Studioで書き出して検証した例では、本文のページ、目次、表紙、奥付が、それぞれ別のファイルとして入っていました。 この構造を知っておくと、崩れたときに「どこを直せばいいか」を自分で決められるようになります。EPUB一般に、表紙や奥付を別ファイルで持つことまで必須という意味ではありません。
この記事では、EPUBの中身に何が入っているのかを確認しながら、目次・表紙・奥付付きの1冊へ仕上げる順番を示します。操作名だけを追うのではなく、「何を決めたら次へ進めるか」が分かる手順です。
目次・表紙・奥付付きへ仕上げる確認順
最初にシリーズ情報を決めます。作品名、作者、発行所、書き出すファイル名、書字方向、言語です。次に巻ごとの情報として、版と発行日、表紙画像を確認します。空欄や組み合わせの問題は、この時点で検証して直します。
続いて、本文に使う原稿を選び、読む順番に並べます。タイトル、本文の各章、奥付の順を見たうえで、どの章を目次へ載せるかも確認します。ファイルの並びと目次への掲載は別の判断なので、順番が正しいだけで終わらせません。
表紙画像と奥付に載せる情報をそろえたら、書き出す原稿と順番をもう一度見直してEPUBを作ります。どの項目から奥付を組み立てるかは制作ソフトによって異なるため、出力後の奥付を本文として読み直します。
最後に、できたEPUBを開き、収録ファイルとパッケージ文書のspineに記録された読む順番を確認します。目次、表紙、奥付が意図した内容かも、それぞれのページを読んで確かめます。設定、収録順、目次、表紙、奥付、書き出し後の確認までを一続きにするのが、完成手順です。
EPUBは「ひとまとまりのフォルダ」
EPUBファイルは、拡張子こそ独自ですが、中身はフォルダのようなものです。解いて開くと、決まった名前のフォルダとファイルが並んでいます。
実際に開発版のrune Studioで書き出したEPUBを開いてみたところ、10個のファイルが入っていました。 内訳は次のとおりです。
W3CのEPUB 3.3仕様では、META-INF/container.xmlはパッケージ文書の場所を示し、既定の読む順番はパッケージ文書内のspineが定義します。この二つを「読み始める場所を示すファイル」と一括りにしません。
- 形式を示す小さなファイル
- 本の構成・書誌をまとめたパッケージ文書の場所を示すファイル
- 見た目を決める記述のファイル
- 本の構成と書誌をまとめたファイル
- 目次のファイル
- 本文のページ（第一章、第二章）
- タイトルページ
- 奥付のページ
- 旧いリーダー向けの目次のファイル
目次も奥付も、独立した1つのファイルとして入っています。 ここが分かると、「目次だけがおかしい」というときに見る場所が1つに定まります。
中を見ずに直そうとすると、当てずっぽうになる
EPUBの中身を知らないまま崩れを直そうとすると、原稿を直しては書き出し、また開いて確かめる、という繰り返しになります。
問題は、直した場所と症状が対応しているかを確かめられないことです。 目次に章が出ないとき、原稿の見出しが原因なのか、目次のファイルが作られていないのか、目次には入っているのに読書アプリが読んでいないのかで、直す場所が違います。
実際にどこへ何が入るのか
書き出したEPUBの中身を読んで確かめました。
書誌をまとめたファイルには、作品名、作者、発行日、言語、発行所、その本を見分けるための番号が入っていました。縦書きに設定した場合は、文字の流れが縦書きであること、ページを送る向きが右から左であることも、ここに書かれていました。
目次のファイルには、章の名前と行き先の並びが入っていました。第一章と第二章が、それぞれ本文のページを指しています。同じ並びが、旧いリーダー向けのファイルにも入っていました。
奥付のページには、作品名、発行日と版、作者、発行所、著作権の表示、フィクションである旨の断りが、読める文章として並んでいました。
確認した10ファイルを役割別に見る
この書き出し例では、収録ファイルを実際に開いて数えた結果が10件でした。本文、目次、タイトル、奥付を別々に読めたため、どの役割の内容を直すのかを切り分けられます。10件という数はこの検証例の結果であり、別のソフトや別の構成へそのまま当てはめません。
表紙を付けると1つ増える
表紙の画像を指定して書き出したところ、読む順番の先頭に表紙のページが増え、収録も増えました。表紙も1つのページとして入ります。 検査では表紙のページが「空のページ」として挙がりますが、画像だけのページなので判定は問題なしのままでした。
画像はページを基準に名前が付け替わる
本文に画像を入れて書き出すと、EPUBの中では原稿に書いた名前ではなく、ページを基準にした名前になっていました。中を解いて元の名前を探しても見つかりません。 突き合わせようとして混乱するのは、たいていここです。
構造が分かると、直す場所が決まる
たとえば「目次に章が出ない」場合。EPUBを開いて目次のファイルがあるかを見たうえで、その中に章が並んでいるかを確認します。ファイルがなければ生成側、ファイルはあって章だけなければ見出しや掲載条件を見直す、というように調査先を分けられます。当てずっぽうの往復が減ります。
向く人と、別の方法が向く人
向いているのは、崩れを自分で直したい人です。 販売先で弾かれたときに、何を直せばいいかを自分で判断できるようになります。
中身を知らなくても本は作れます。 順調に出せているなら、無理に覚える必要はありません。困ったときに読み返せば足ります。
なお、確かめたのは1つのEPUBの中身と検査の結果までです。すべてのEPUBがこの構成とは限りません。 作るソフトによって、ファイルの数も名前も変わります。
まとめ
- EPUBは複数のファイルがひとまとまりになったもので、実際に確かめた例では10個入っていた
- 目次も奥付も、独立した1つのファイルとして入っている
- 書誌をまとめたファイルには、作品名・作者・発行日・言語・発行所と、縦書きなら読み方向も入る
- シリーズ情報、原稿の順番と目次掲載、表紙、書き出し計画、検査の順で仕上げる
- 構造が分かると、崩れたときに直す場所を自分で決められる
次の一歩として、シリーズ情報と原稿の順番をそろえ、目次へ載せる章と表紙を確認してから1本書き出してください。書き出したEPUBを開き、パッケージ文書のspineと各ページを確認すれば、目次・表紙・奥付付きの完成形を自分で確かめられます。
