入稿後の手戻りを防ぐ!EPUBが崩れる問題、目次・章順による崩れを見分ける

epub 崩れる症状が章の並びや目次に出たら、本文の文字コードより先に「本へ収録する順番」と「目次へ載せる章」を別々に調べます。今回の四章標本は4→1→2→3の順で収録し、章1だけを目次から外しました。出力はspine 7項目、nav 3件、NCX 3件となり、この差を構造から確認できました。

読書順と目次掲載を二つのリストにする

EPUBには、本文を読む順番を持つspineと、読者が選ぶ案内を持つnav.xhtmlがあります。目次から外した章もspineに残せます。奥付や短い前書きなど、収録するが目次には出さない項目があるためです。

崩れを調べる前に、原稿名、希望する読書順、目次掲載の有無を表へ書きます。画面の一覧だけを見ていると、ドラッグ順とチェック状態を同じ設定だと思いやすくなります。二列で管理すれば、章が消えたのか案内だけ消えたのかを分けられます。

章順と目次設定の不一致を直す検査では、見た目の違和感を「本文順」「ラベル」「リンク先」のどれかへ分類します。これが戻し先を決める鍵です。

たとえば「第三章が先に出る」は本文順の疑い、「第三章がメニューにない」は掲載設定の疑い、「第三章を押すと第二章へ行く」はリンク先の疑いです。同じ“崩れ”という言葉でも、観察文を一つ書くだけで調べる場所が変わります。

わざと崩した四章で境界を測った

専用ワークスペースへ章1から章4の合成原稿を作りました。EPUBへ渡す順は章4、章1、章2、章3です。さらに章1を目次対象から除外しました。意図的に通常と違う条件を作ることで、生成物のどこへ反映されるかを見ています。

出力後のspineはタイトル、nav、本文4件、奥付の計7項目です。本文の格納順は渡した順を保ちました。navには章4、章2、章3の三件が入り、章1はありません。NCXも同じ三件でした。

すべてのnavリンクとNCXのsrcは実在するXHTMLへ到達し、欠落資源は0件、ローカル検査はvalid=trueです。これは構造上の結果であり、第三者リーダーのメニュー表示を操作した結果ではありません。

spineを読めば本文の順番が分かる

目次だけを開くと、章1がないため「EPUBから削除された」と誤解するかもしれません。spineを見ると、章1のXHTMLは二番目の本文として残っています。収録と案内の違いを知らないと、正常なパッケージを壊れていると判断します。

希望順とspineが違う場合は、Rune Studioへ渡したファイル順へ戻ります。本文ファイル名を変える前に、選択順の記録と生成順を比較します。順番だけの問題なら、文字を再保存したり画像を作り直したりする必要はありません。

navとNCXは掲載対象を照合する

目次に載せる三章は、ラベルと参照先の組で確認します。今回のnavは章4→章2→章3で、NCXも同順です。三件という数だけではなく、各ラベルが対応する本文へ到達することまで読みました。

目次ラベルが古ければ章題の採用元を直し、hrefが切れていれば収録パスを調べます。NCXが違う場合は互換文書の生成結果として切り離します。旧リーダーでの動作は未実測なので、構造一致から互換性を保証しません。

本文の見た目が崩れているのにspineとnavが正しいなら、CSS、画像参照、文字コードなど別の層へ進みます。章順検査を何度もやり直しても、その問題は直りません。

再エンコードせず最小の設定へ戻る

章が想定外の位置にあるときは並び順だけ、目次から欠けたときは掲載チェックだけを変更します。一回の修正後に別名EPUBを出し、spine、nav、NCXをもう一度読みます。複数の設定を同時に直すと原因を確認できません。

今回の標本なら、通常の1→2→3→4へ戻したい場合は入力順を変更します。章1を目次へ出したい場合は除外指定を外します。どちらも原稿本文の符号変換とは無関係です。

修正版を保存するときは、前のEPUBを上書きしません。変更した列をファイル名と記録へ残し、二つのspineとnavを比較します。改善が見られなければ、元の合格部分へ戻せるからです。

見た目のレイアウト崩れが同時に起きている場合も、まず章順を確定します。その後にCSSや画像を調べれば、読む順番が動くたびにレイアウト検査をやり直す無駄を減らせます。

合格条件は、spineが希望する読書順を持ち、navとNCXが目次掲載表と一致し、全参照先が存在し、欠落資源が0件であることです。これがspineとnavの切り分けです。Rune Studioは章順と目次掲載を指定してEPUBを作る候補ですが、対象リーダーでの表示確認は別に行います。まず二列の表を作れば、「崩れた」という曖昧な症状を一つの設定へ絞れます。

共同制作では、並び順表を編集担当が確定し、出力担当が観測したspineを別列へ記入します。同じ人が記憶で両列を埋めるより、意図と結果の差を見つけやすくなります。目次掲載表も同じ方式で照合し、章1を外した理由のような編集判断を残します。

読者報告を受けた際は、どの章の次に何が出たか、目次に何が表示されたか、リンク先がどこだったかを分けて聞きます。三つの観察がそろえば、spine、navラベル、hrefのどこへ戻るかを迅速に決められます。修正前後の対応表も一緒に保存します。