EPUB記法の色分けは、OPFやXHTMLのどこが宣言で、どこが本文かを見分ける補助にはなります。しかし、色が付いたから構文が正しいとは言えません。色分けは読むため、構造検査は間違いを見つけるため、と役割を分けてください。
今回確認できたのは、短いOPFでXML宣言と本文に色の差があったことだけです。metadata、manifest、spineの各要素が別々の色になるところまでは確認できませんでした。したがって、この記事では「EPUBの要素別に色分けできる」と断言せず、見えた範囲と別の検査方法を示します。
OPFの三領域を色ではなく名前で読む
OPFでは、書誌情報を持つmetadata、本に含むファイルを列挙するmanifest、読む順番を示すspineが重要です。これらの文字列を検索し、開始タグと終了タグ、参照IDの対応を確認します。
色が同じでも要素名は読めます。逆に色が違っても、閉じタグの不足や存在しないID参照が正しいことにはなりません。最初に要素名で領域を分け、その後に色を視線の補助として使います。
小さなOPFで表示を確かめる
本番のEPUBを直接編集せず、OPF、XHTML、CSSを一つずつ持つ小さな複製を使います。Rune StudioでOPFを開き、XML宣言、package、metadata、manifest、spineの順に見ます。
確認用ファイルは242バイトで、XML宣言が青、本文の要素列が白く表示されました。色差は見えましたが、OPF内部の各役割が別色へ分かれたわけではありません。この観察だけで全XML方言の表示を説明することもできません。
色分けでできること、できないこと
できるのは、長い記法の中で視線の区切りを作り、宣言や文字列の位置へ気づきやすくすることです。できないのは、参照先ファイルの存在、IDの一致、読む順番、目次の欠落、EPUB仕様への適合を保証することです。
色が突然消えた場合も、構文エラーと決めつけません。大容量モード、ファイル種類、設定、テーマの順に確認します。問題箇所の前後を検索し、色に頼らずタグ名を読める状態を保ちます。
30万文字を越えるファイルでは別の道具へ切り替える
Rune Studioは30万文字以上のファイルで、Markdown・EPUB記法の色分け、編集記号、ハイライト、行番号、常時の文字数計算などを停止し、表示負荷を抑えます。色が付かないのは構文が壊れたからではなく、大容量として表示補助が止まった可能性があります。
巨大なXHTMLを確認する場合は、固有のタグやIDをファイル内検索し、必要な範囲だけを小さな複製へ取り出して読みます。文章編集と検索は残るため、色なしでも対象へ移動できます。
構造の正しさは生成物で確認する
EPUBを出力したら、nav、manifest、spine、画像欠落などを構造検査で確かめます。OPFの色ではなく、実際に参照されるファイルと読む順番を見ます。さらに外部リーダーで章移動と表示を確認します。
EPUB 3の構造を調べるときは、W3C EPUB 3.3仕様のような一次資料を基準にします。色分けのルールを仕様だと思い込まないことが大切です。
見落としを減らす二段階
第一段階は色分けと検索で、編集対象の領域を見つけます。第二段階は構造検査と外部リーダーで、参照と表示結果を確認します。第一段階で異常を見つけても、第二段階で理由が分かるまで公開用EPUBへ反映しません。
Rune Studioの色分けは、編集記法を読む補助として使い、検証器の代わりにしないでください。まず短いOPFを開き、XML宣言と本文の見え方を確かめ、その後に要素名検索と構造検査へ進みましょう。現行機能は商品ページで確認できます。
色に頼らない差分メモを作る
OPFを直す前に、変更する要素名、現在値、変更後の値を三列でメモします。たとえば「metadata／言語／ja」「spine／第二章の順番／第三章の後」のようにします。色が変わらなくても、何を直したかを追えます。
修正後は、同じ要素名を検索し、重複や旧値が残っていないかを見ます。色分けは視線を助けますが、変更履歴にはなりません。差分メモ、構造検査、外部リーダーの三つを使えば、テーマや大容量モードで色が消えても検証を続けられます。
構文の編集は、生成元がある場合には生成元へ戻って行います。出力済みEPUBのOPFだけを直すと、次の生成で変更が消えるためです。色分けで問題を見つけたら、ウィザードの書誌情報や章順など、同じ値を作る元設定を探して修正します。
