EPUBファイルの作り方で迷ったら、画面で縦書きに見えたことだけを完成条件にせず、EPUBの内部にある「読む順番」「目次」「本文」「表紙参照」「縦書き指定」を別々に確認します。この記事では、三章小説、目次三項目、表紙一枚、奥付一枚を標本に、nav、spine、OPFなどの役割と、何を照合すればよいかを説明します。販売先の審査と固定レイアウトEPUBは扱いません。
標本の合格条件は、①container.xmlから正しいOPFへたどれる、②OPFのmanifestとspineに必要な本文・nav・表紙が登録される、③navの三項目が各章へ移動する、④本文が意図した縦書き指定を参照する、の四つです。見た目と内部構成を同じ欄で合格にしないことが出発点です。
EPUB内部の役割を先に分ける
EPUBは複数のファイルをまとめたパッケージです。一般的なEPUB 3では、ルートの「mimetype」はパッケージの種類を示し、META-INF/container.xmlはパッケージ文書であるOPFの場所を示します。OPFは本の部品一覧と読む順番を管理する中心です。
OPFの中でも役割を分けます。metadataはタイトルや著者などの書誌、manifestは本文・nav・CSS・画像などのファイル一覧、spineは読者が読む順番です。nav.xhtmlは目次のリンク、各章のXHTMLは本文、CSSは縦書きなどの表示指定を担います。「OPFがある」だけでは、必要な部品が登録され、順番が正しいとは限りません。
三章標本の確認対象を固定する
三章小説の標本には、章IDをCH01、CH02、CH03と付け、navに三項目、表紙画像に一枚、奥付に一つの本文ファイルを用意します。確認表は「対象」「期待する状態」「実際の状態」「失敗時の戻り先」の四列にします。
たとえば、対象がspineなら「CH01→CH02→CH03の順でitemrefが並ぶ」が期待状態です。navなら「目次のCH02を選ぶとCH02のXHTMLへ移る」、manifestなら「三章、nav、CSS、表紙画像の各itemが登録される」、縦書き指定なら「章のXHTMLが対象CSSを参照し、意図したwriting-modeが確認できる」が基準です。三章すべてを見ずに一章だけで合格にしません。
navとspineを照合する
navは読者が目次から移動するための案内で、spineは本文を読む順番です。二つは似ていますが、同じ役割ではありません。navのCH01、CH02、CH03が、それぞれmanifest内の本文itemの正しいファイルを指すかを確認し、spineのitemrefがCH01、CH02、CH03の読む順番になっているかを別欄で見ます。
目次の表示名が正しくても、リンク先がCH03なら不合格です。反対にspineが正しくてもnavにCH02がなければ、目次からの移動は未確認です。navのリンクが切れていたらnav.xhtmlと対象XHTMLのid・ファイル名へ戻り、読む順番が違ったらOPFのspineとitemrefへ戻ります。本文の文章を先に直して原因をぼかさないことが重要です。
OPF・manifest・表紙参照を見る
container.xmlを開き、rootfileのfull-pathが実際のOPFの場所と一致するかを確かめます。次にOPFのmanifestで、CH01〜CH03の本文、nav、CSS、表紙画像が登録されているかを見ます。spineのitemrefはmanifestのitem idを参照するため、manifestにないidや、存在しないファイルを指すidは不合格です。
表紙は画像がフォルダにあるだけでは足りません。manifestの表紙画像itemが実ファイルを指し、EPUB 3の表紙画像として示されているかを確認します。画像が表示されない場合の戻り先は本文XHTMLではなく、OPFのmanifest、表紙画像のパス、表紙を示す指定です。奥付が欠けた場合は、奥付XHTMLがmanifestとspineに含まれるかを見ます。
縦書き指定と本文CSSを確認する
章のXHTMLが参照するCSSを特定し、縦書きの指定がその本文へ適用されるかを確認します。一般的には「writing-mode: vertical-rl;」が縦方向と右から左への列送りを指定しますが、この一行があるだけで全章の表示が合格になるわけではありません。CH01の「午前10時」「本当!?」「ルビ」、CH02の同じ種類の箇所を実際に読みます。
数字が横向きなら、まず対象XHTMLの文字列とCSSの指定範囲へ戻ります。章だけ横書きなら、その章が参照するCSSのリンクへ戻ります。ページを送る向きが違う場合は、本文の文字を直すのではなく、spineのページ進行方向などパッケージ側の設定を確認します。内部の役割をまたいで一度に修正しないことが判定を保ちます。
Rune Studioは出力候補として扱う
現行Mac版の公開機能資料では、Rune Studioは「vertical-rlの縦書きプレビューと、右開き・縦中横・記号処理を含むEPUB 3出力を備える」という機能範囲が確認できます。そのため、三章標本のEPUB候補を作り、本文表示と内部構成を確認する作業に使う候補として記載できます。
ただし、これは公開資料で確認した機能範囲であり、Rune Studioがnav・spine・OPFの各ファイルをどのように見せるか、上の三章標本が合格したか、販売先が受理するかを示すものではありません。製品の機能範囲と、出力したEPUBを自分で確認した結果を別々に記録してください。
最初に三章の対応表を作る
まず、CH01、CH02、CH03を縦に並べ、対応する本文XHTML、navの項目、manifestのitem id、spineのitemrefを一行ずつ書きます。表紙と奥付は別行にし、container.xmlからOPFへたどる経路も記録します。確認順は、mimetypeとcontainer.xml、OPFのmanifest、spine、nav、各章のCSS、表紙参照です。
問題が出たら、navの移動先、spineの順番、manifestの部品一覧、CSSの縦書き指定、表紙の参照先のうち、該当する一欄だけへ戻ります。修正後は変更した欄と、影響を受ける章だけを再確認し、未確認を合格へ繰り上げません。EPUBファイルを作るときは、見た目を読む作業と、内部の役割を照合する作業を分けることで、どのファイルを直すべきか判断できます。
この対応表は保存して、作業を中断したときの戻り先にします。再開手順は、①保存済み内部構造マップで最後に確認した章IDと版名を読む、②container.xmlのrootfileから同じOPFへたどる、③その行のmanifest item id、spine itemref、nav項目、CSS、表紙参照を実ファイルと照合する、④一致した章から未確認の欄だけを続けて確認し、実際の状態と失敗時の戻り先を更新する、の順です。CH01〜CH03を毎回最初から読み直すのではなく、保存記録の最後の確認位置から再開します。ここで扱うのは保存済み内部構造マップから手作業で同じ要素へ戻る確認であり、アプリ終了・再起動後の作業状態自動復元を製品結果として扱いません。
