違いを見逃さない!EPUB Editor、メタデータ・目次機能を妥協しない判断軸

書誌と目次の四つの不一致から正本を特定するアイキャッチ

EPUB Editorでメタデータと目次を設定できても、作品名や章題を複数画面へ入力する設計では、片方だけ直して不一致が残ることがあります。意図的に異なる値を入れ、どの入力がOPF、nav、NCX、spineへ届くかを確認すると、正本を一つにできる候補を選べます。

この記事は目次・表紙・奥付の三要素を試す記事でも、著者名変更後の非対象保持を測る記事でもありません。作品名、著者、章題、章順の四つについて、入力正本と生成物の相互整合を調べます。

二章へ四つの不一致を作る

販売用原稿を使わず、第一章と第二章の試験作品を作ります。正解表には、作品名「青い駅」、著者「山田A」、章題「出発」「再会」、読書順「出発→再会」を書きます。

候補の別の入力場所には、意図的に旧値を入れます。作品名「青い町」、著者「山田B」、第二章題「帰還」、章順「再会→出発」です。どちらが正しいか迷わないよう、正解表を先に固定します。

候補が一つの入力場所しか持たない項目は、不一致を作る必要がありません。それ自体を単一入力として記録します。複数入力を見つけた項目だけ、どちらが生成先へ届くかを試します。

入力場所の役割を記録する

作品名と著者について、作品設定、巻設定、奥付原稿、インポート元など候補内の入力場所を一覧にします。章題は原稿見出し、章設定、目次ラベルを分けます。章順はファイル名、ファイルツリー、明示的な出力順を分けます。

各入力に、編集正本、表示用別名、生成時の一時値、用途不明のどれかを仮に付けます。ヘルプや仕様で説明されている場合は出典を記録し、説明がない場合は生成試験で判定します。

同じ言葉を二回入れること自体が失格ではありません。奥付の表示名と書誌のcreatorが意図的に違う場合もあります。違いの意味と生成先を説明できるかが判断点です。

一回目のEPUBを四か所で照合する

不一致を残した状態で、試験EPUBを別名生成します。OPFでtitleとcreator、navで目次ラベルと順序、NCXで同じラベルと順序、spineで読書順を確認します。本文XHTMLの見出しも記録します。

正解表と一致した値、旧値が出た場所、候補が自動修正した場所を表へ書きます。navが正しくてもNCXが旧章題、目次順が正しくてもspineが逆なら不一致です。

比較表の列は、入力場所、旧値、変更値、OPF、nav、NCX、spine、解釈に固定します。スクリーンショットだけより、古い構造を横並びで見つけやすくなります。

対照行を二つ加えます。作品名の生成では変更していない著者、章順の生成では変更していない作品名が保たれることを確認します。対照行が変わったら、資料上必要な再生成、要確認、許容不可のどれかへ分類してから続行します。

最低一つの実リーダーで生成目次を開き、二つのリンクをたどります。内部ラベルが合っても、fragmentが別の見出しを指す場合があります。リーダー結果はパッケージ検査と分け、一つのリーダー成功を全環境互換とは扱いません。

内部検査のissues 0は、仕様上の欠落がない一つの結果です。作者の正解表と意味が一致することは別に確認します。

正本一項目だけ直して再生成する

一回目の結果から、作品名の入力正本だと判断した場所だけを「青い駅 改訂」へ変えます。他の入力場所は旧値のまま残し、第二のEPUBを別名生成します。

OPF、nav、NCX、本文見出しのどこが更新されたかを比較します。作品名を一か所直しただけで無関係な章順や著者が変わった場合は要確認です。何も変わらないなら、正本の仮説が違います。

次に章題または章順を一項目だけ直し、第三のEPUBを作ります。一度に複数を直すと、どの入力が効いたか分からなくなります。

三つの入力型へ分類する

単一入力型は、一か所の正本から必要な生成先へ値が届きます。表示用の別名がある場合も、役割が明示されていれば含めます。重複入力型は、同じ判断を複数箇所へ手動入力し、同期確認が必要です。

不明型は、どの入力が優先されるか再現できない、または生成ごとに結果が揺れます。不明型は保留にし、完成EPUBの直接修正で隠さないでください。

重複入力型を採用する場合は、作品名、著者、章題、章順のチェック表を作り、生成前に全入力を照合します。単一入力型でも、生成後の四か所確認は最初の作品で行います。

一回の修正費用も採点します。触った入力場所数、確認した生成構造数、比較表を正解へ戻すまでの分数を記録してください。入力場所が明示され変更頻度が低ければ重複入力型も採用できますが、同じ章題を隠れた複数画面へ毎回コピーする型は保留に近づきます。

rune Studioの既存段階4検証では、二章へ作品名、著者、巻、版、発行日、書字方向、章順を設定し、5,444バイトのEPUBを生成しました。navとNCXがあり、issues 0でした。既存の生成前確認画面では、作品名・著者・版・発行日と、第一章・第二章を含むページ順、出力ファイル名を確認しました。これは設定・生成・内部検査と生成前画面の実績で、本記事の意図的不一致や入力優先順位を試した結果ではありません。

Rune StudioのEPUB作成画面で書誌、二章のページ順、出力ファイル名を確認するページ6
ページ6「確認」で、書誌、第一章・第二章のページ順、出力ファイル名を生成前に確認する画面。

close/open後にも正本を説明する

候補を閉じて再度開き、作品名、著者、章題、章順の正本入力を一つずつ示します。前回の生成結果を見ずに、どこを直せば次の出力が変わるか説明します。

説明できたら一項目を元へ戻し、別名再生成します。結果が予測と一致すれば運用を再現できます。候補を開いている間だけ分かる一時状態に依存するなら、手順書を追加するか保留します。

結論:入力正本と生成四か所の整合で選ぶ

EPUB Editorのメタデータ・目次機能は、作品名、著者、章題、章順に意図的不一致を作り、OPF、nav、NCX、spineを照合して選びます。一項目ずつ正本を直し、別名再生成してください。

入力場所の数が少ないことだけでなく、各入力の役割と優先順位を説明でき、close/open後も同じ生成結果を予測できることが、妥協しにくい判断軸です。