EPUBのOPFを確認するときは、難しいXMLを上から読む必要はありません。metadataは「誰の何という本か」、manifestは「何が入っているか」、spineは「どの順で読むか」と、三つの質問へ分けます。作品情報をそろえる作業と、本文の欠落を探す作業を混ぜないことが重要です。
metadataは作品カードと照らす
タイトル、著者、言語、出版社、識別子、更新日時などがmetadataの対象です。三章の本なら、まず作品情報カードの値と一項目ずつ比べます。タイトルが正しくても言語が違えば、閲覧環境での扱いへ影響する可能性があります。
シリーズ名や巻番号を使う場合は、その値も別に読みます。ここでは「本文ファイルが三つあるか」は判定しません。それはmanifestとspineの仕事です。書誌の確認中に章数を数え始めると、どの問題を解いているのか曖昧になります。
manifestは荷物の一覧
manifestでは本文XHTML、スタイル、nav、NCX、画像など、パッケージが使う資源を見ます。元原稿に画像二枚があり、完成物で使うなら、それらに対応する資源が収録されている必要があります。未使用画像がフォルダにあるだけなら、必ずしもmanifestへ入る必要はありません。
項目があるだけで安心せず、リンク先のファイルが実際に存在するかも確認します。資源一覧に名前があるのにファイルが欠けていれば、読者には表示できません。
spineは読者が進む列
spineには本文の既定順が並びます。タイトルページ、nav、第一章、第二章、第三章、奥付という流れを期待するなら、その順で参照されるかを見ます。manifestに第三章があってもspineに入っていなければ、通常のページ送りで到達しない可能性があります。
W3C EPUB 3.3も、manifestを資源一覧、spineを既定の読む順番として定義しています。この標準の役割をRune Studio独自機能として説明しないようにします。
Rune Studioの入力から三欄へつなぐ
Rune StudioではEPUBウィザードの「シリーズ情報」と「メタデータ」が作品情報へつながります。「ファイル選択」と「チャプター順」で選んだ原稿、目次掲載、順番が、収録資源と読む順番へ反映されます。「確認と出力」で入力を見直してから、EPUBフォルダへ生成します。
三章の確認用EPUBでは、OPFのmanifestに本文、スタイル、nav、NCX、タイトル、奥付が記録され、spineはタイトル、nav、本文三章、奥付の六項目でした。シリーズ名と巻番号2の値も確認でき、ローカル構造検査は有効でした。これはパッケージ内部の静的な結果です。
症状から見る欄を選ぶ
著者名が違うならmetadata、画像が消えるならmanifestと実ファイル、章が飛ぶならspineを優先します。三欄を全部同時に直そうとせず、一つの症状に一つの問いを当てます。問題がない欄まで編集すると、新しいずれを作りかねません。
OPF検査のゴールはXMLを暗記することではなく、「本の身元・荷物・順路」を説明できることです。Rune Studioで生成した本でも、別ツールの本でも、この三分法は使えます。製品固有の生成範囲は現行機能ページで確認してください。
三欄の確認順は症状で変える
新規出力の最終確認ならmetadata、manifest、spineの順で全体を見られます。修正作業では、症状に近い欄から始めます。たとえば章がページ送りから消えたならspine、画像だけが空ならmanifest、書店で著者名が違うと指摘されたならまずmetadataです。
ただし一つの欄だけで原因が完結するとは限りません。spineが参照するIDはmanifestの項目へつながるため、順番を見たあと資源の存在も確かめます。確認範囲を広げるときは「なぜ次の欄を見るか」を言葉にします。XMLの行数を追うのではなく、本の身元、荷物、順路という三つの意味へ戻れば、専門用語に迷いません。
画像二枚のmanifestを読む例
map.png と chart.png を使う本なら、manifestでそれぞれの資源とメディア種別を見て、本文の参照先とつなぎます。表紙画像は本文画像と同じ画像形式でも、coverとしての役割が別に記録されることがあります。画像という一分類だけでまとめません。
スタイルシートも資源です。本文ファイルがそろっているのに見た目が崩れる場合は、CSSの宣言と実ファイルを確認します。ただし端末固有のCSS対応まではOPFの存在だけで判断できません。静的な資源の有無を確認したあと、対象リーダーで表示を見ます。manifestは必要条件を調べる場所で、視覚品質の十分条件ではありません。
