再版や差し替えで表紙だけを新しくしても、EPUBの中に旧著者名や誤った言語が残っていれば、引き渡しは完了していません。画面に見える表紙と、パッケージに記録される書誌情報は別々の場所にあるからです。epub メタデータを確実に整えるには、入力カードと、出力後のOPF・目次・spine・表紙資源を一冊ずつ対応させます。
固定検証では四章の合成原稿、版3.1、表紙PNG一枚を使いました。主証拠は表紙追加後のstudio-415-260903.110000.epubだけです。途中出力の件数を混ぜず、最終EPUBのSHAを起点にすべての値を読みます。
出力前に一冊分の版カードを確定する
版カードには、タイトルSTUDIO-415 検証本、著者検証用著者、発行者検証用出版者、言語ja、版3.1、表紙cover-cycle4.png、本文四章を書きました。タイトル、著者、発行者、言語はOPFで確認する値です。版3.1はRuneの巻設定と出力後の奥付で追います。表紙はOPF manifestのcover-image役割と、cover.xhtmlからの参照で確認します。
同じカードにすべてを書いても、合否は一括にしません。著者名が一致しても言語が違えば不合格です。表紙ファイルがZIP内にあってもcover-imageとして登録されていなければ不合格です。章が四つあっても目次リンクが三つなら、読者がたどる入口が欠けています。
入力を確定したらカードに日時を付け、以後の修正は一欄ずつ行います。曖昧な「最新版」という名前ではなく、値とファイルSHAで版を識別します。
Runeへ書誌・版・表紙を別操作で渡す
検証ではrune epub series setでタイトル、著者、発行者、言語を設定し、rune epub volume set --number 0 --version 3.1で版を指定しました。続いてrune epub cover setで表紙PNGを登録し、四つの章ファイルを選択して順番を固定してから、決定的な時刻を与えてEPUBを出力しました。
操作を分ける理由は、失敗箇所をカードの一欄へ戻すためです。たとえば言語だけが違うのに表紙まで設定し直すと、新たな差分が増えます。各コマンドのJSON、標準エラー、終了コードは保存されていますが、終了コード0は入力を受け取ったことしか示しません。最終判断は閉じたEPUBをもう一度開いて行います。
本文四章はchapter-1.mdからchapter-4.mdです。選択結果と目次対象を四件として記録し、順番を入れ替えた別案は最終候補へ混ぜません。
最終EPUBをSHAから開き直す
主証拠のファイルはstudio-415-260903.110000.epub、SHA-256はc0db14b45646f26b7e9cf675a07f446021d85d0596cdc1a2b6055fee31d64158です。サイズは17,551バイト、ZIPのentryは14件でした。以降のOPF、nav、spine、画像の値はすべてこの一冊から取得しています。
ここでファイル名だけを照合すると、途中版と最終版を取り違える可能性があります。引き渡し票にはSHA、出力時刻、ファイルサイズを組にし、検査ツールにも同じパスを渡します。Runeのローカル検査はvalid=true、issuesは空でした。
ローカル検査が通っても、個々の書誌値をカードへ戻す作業は省けません。構造的に読めるEPUBと、今回の出版情報が正しいEPUBは同義ではないからです。
OPF四値と版3.1をそれぞれ読む
最終OPFから読んだ値は、title=STUDIO-415 検証本、creator=検証用著者、publisher=検証用出版者、language=jaです。四つとも版カードと一致しました。書誌値は似た文字列ではなく完全一致で判定します。余分な空白、旧表記、言語コードの違いも不一致として扱います。
版3.1は巻設定の入力と、同じ最終EPUBの奥付にある電子書籍 ver 3.1 発行を対応させます。OPF四値の一つとして数えたり、タイトル文字列へ混ぜたりしません。これにより「メタデータ四値が合った」と「意図した版が出力に反映された」を別々に説明できます。
値が違う場合は、まず版カードが正本かを確認します。カードが正しければ該当欄だけをRuneで修正し、新しい名前で再出力します。古いEPUBを上書きせず、修正前後のOPFまたは奥付を比較します。
八つのspineと四つの目次を数える
最終EPUBのspineは8項目です。順にcover.xhtml、title.xhtml、nav.xhtml、p001.xhtml、p002.xhtml、p003.xhtml、p004.xhtml、colophon.xhtmlが並びます。本文四章だけを数えるのではなく、表紙、タイトル、目次、奥付を含めた読書順として確認します。
navには四つの章リンクがあり、STUDIO-415 検証章1から検証章4までがp001.xhtml〜p004.xhtmlへ接続しました。各リンク先もZIP内に存在します。spineが8でもnavが4とは限らないため、二つの件数を別欄に残します。
章リンクが三つしかない失敗では、章ファイルを追加し直す前に、四章目の目次対象フラグとリンク先を確認します。spineの本文位置が正しければ、その合格を保ったままnavだけを直し、再出力後に四リンクをすべて開き直します。
表紙一件を役割と参照の両方で確かめる
manifestの画像資源は一件で、Images/cover.pngにcover-image属性が付き、cover.xhtmlは../Images/cover.pngを参照していました。本文画像は入力していないため、このEPUBの画像参照も表紙の一件だけです。パッケージ検査の欠落資源は0件でした。
表紙が画面に表示されたという印象だけでは、manifest上の役割を証明できません。逆に、cover-imageがあっても、すべてのリーダーで同じ比率や余白になるとは限りません。本稿の合格は、最終EPUB内に表紙資源一件、表紙役割一件、XHTML参照一件があり、その参照先が存在することです。
表紙が欠けた場合はカードの表紙パス、cover setの結果、manifest、ZIP実体を順に確認します。書誌四値と四章の順番は凍結し、表紙経路だけを修正します。
一冊の引き渡し条件と未実測範囲を残す
引き渡しの合格条件は、同じSHAの最終EPUBでOPF四値がカードと一致し、版3.1を奥付で確認でき、spineが8、navが4、cover-imageが1、欠落が0であることです。どれか一つでも別ファイルから取った値なら、検査をやり直します。
今回の固定検査は、販売先へのアップロード、ストア上の版表示、KDPの受理、端末や第三者リーダーでの描画を測っていません。表紙の著作権や利用許諾も構造検査の外です。これらは同じ最終SHAを渡した次工程で、別の担当と合格票を使って確認します。
Rune Studioの現行機能は公式サイトで確認し、OPF、spine、nav、manifestの一般構造はW3C EPUB 3.3と区別して扱います。一冊の版カードと一冊の最終EPUBを対応させれば、表紙だけが新しく見える状態に安心せず、書誌・版・読書順まで根拠を持って引き渡せます。