KDPへ進める前にローカル合格線を引く
KDP向けの画像入りEPUBを作るときは、「Creatorから出力できた」と「KDPへ提出できる」を同じ判定にしません。先にローカルパッケージの合格線を引き、その後にKindle PreviewerやKDP側の確認へ進みます。
記事固有の標本は本文3章、本文画像3枚、表紙1枚です。出力後は収録画像4件、欠落0件、spine 7、navとNCXの章リンク各3件、valid=trueでした。statusはpassedですが、これはローカル検査の合格です。KDP受理の確認ではありません。
3章・本文画像3枚・表紙1枚を提出前標本にする
chapter01.mdからchapter03.mdまでの各章に本文画像を1枚ずつ置き、別に表紙を設定しました。開始値は本文3章、本文画像3、表紙1、期待収録画像4です。表紙を本文画像と分けて数えることで、「本文は揃ったが表紙登録がない」という差を見つけられます。
この標本の判断は、3章が読み順へ入り、4画像がパッケージへ入り、欠落が0になるかです。KDPの画面や実機は、まだ標本の外側です。
一般手順はローカル検査と販売先検査を分ける
まず原稿内の画像参照と表紙設定を数え、EPUB出力後にmanifest、画像ファイル、spine、nav、NCXを照合します。ローカル値が揃ってから、Kindle Previewerで各章と画像を確認し、最後にKDPへアップロードします。
KDPの公式ヘルプはEPUBを対応形式として案内し、アップロード前のKindle Previewer確認を推奨しています。したがって、ローカルvalid=trueだけで販売先検査を省略しません。
固有実測はCreator出力の内側まで行った
Stage 4では、3章、本文画像3枚、表紙1枚を作り、シリーズ名・巻数・表紙を設定して対象原稿を選択しました。計画確認、EPUB生成、検査、package、nav、NCX、章XHTMLの読取まで実行しています。command_countは10です。
移動後の参照更新を扱う公開機能はありますが、この証拠で参照更新を行う場合は専用コピー上の明示CLIです。Finderやクラウド移動に対する自動追従を、この出力結果から主張しません。
ローカル結果は画像4・欠落0・章リンク3
実測値はinput_chapters=3、inline_image_files=3、cover_files=1、image_count=4、missing_images=0、spine_count=7、nav_item_count=3、ncx_item_count=3、valid=trueです。navとNCXはいずれも存在しました。
3章よりspineが多いのは、生成される構造ページが含まれるためです。判断の中心は、3章へのリンクがnavとNCXに3件ずつあり、本文画像3枚と表紙1枚が合計4件として収録され、欠落が0であることです。
別の共通Stage 4では5章、画像1枚、version 1.3の標本でspine 9、欠落0、nav・NCXあり、valid=trueを確認しています。これは別標本なので、今回の4画像とは合算しません。
passedの外にはPreviewerとKDPが残る
未確認なのは、画像の視覚品質、代替テキストの適切さ、Kindle Previewerでの見え方、端末差、KDPアップロードと受理です。今回のvalid=trueはローカルパッケージ検査の結果であり、KDPの審査や販売可否を示しません。
画像数が4でなければ本文参照または表紙設定へ戻り、章リンクが3でなければ原稿選択と順序へ戻ります。ローカル値が揃わない状態でKDPへ進むと、販売先で原因を探す範囲が広がります。
Rune Studioの範囲は生成物を用意するところまで
Rune Studioの公開仕様では、Mac上のワークスペースからEPUB 3を生成し、content.opf、nav.xhtml、NCX、本文、画像、表紙をパッケージへ組み込めます。相対パス更新機能もありますが、外部URLやページ内アンカーは更新対象外です。
製品が担うのはローカル生成と参照管理です。KDPの受理やKindle端末上の表示は外部サービス・実機の範囲なので、製品機能や今回のStage 4結果へ含めません。
ローカル合格後にKDP確認へ渡す
今回の3章標本は、画像4、欠落0、章リンク各3、spine 7、valid=trueでローカル合格線を通過しました。次の工程はKindle PreviewerとKDPであり、そこは未確認のまま明示的に残します。
KDP向けEPUBで手戻りを減らす要点は、Creator出力の合格と販売先の合格を二段階にすることです。ローカルで数値が外れたら入力へ戻り、揃ったときだけ外部確認へ進みます。
