事故を持ち越さない!EPUB画像が表示されない問題、使用中画像の削除を警告で止める

epub 画像 表示されない問題を直すときは、画像を消して挿し直す前に「原稿の参照先」「EPUBへの格納」「読書画面での表示」を分けます。最初の二つはファイルから検査できますが、最後の見え方はリーダーでの確認が必要です。とくに使用中画像を削除すると、原稿中の相対パスだけが残り、書き出し直前まで気づかないことがあります。

削除する前に参照元を見つける

Markdownの画像は、たとえば![章扉](images/chapter-1.png)のように原稿から画像へ道筋を持っています。ファイルをFinderで別の場所へ動かしたり、画像名だけ変えたりすると、この道筋は古いままです。まず検索で画像名を探し、どの章が何回参照しているかを数えます。表紙に使っている画像は本文参照とは別の設定に登録されるため、本文だけを検索して「未使用」と決めないことも重要です。

Rune Studioの公開資料には、使用中画像の削除時に警告する機能が説明されています。この警告は削除事故を止める入口ですが、警告を閉じただけで参照が直るわけではありません。今回の検証では警告ダイアログの表示、ボタン文言、削除を止めた瞬間の画面を操作していません。したがって、以下では実際に取得できた欠落参照の拒否と完成EPUBの構造を根拠にします。

旧パスを残した負の標本で止まる位置を確かめた

専用の合成原稿では、存在しない画像を指すbroken.mdを用意しました。正常な画像を削除する代わりに、複製側だけで参照先を欠落させた安全な負の標本です。epub validateへ渡すと、完成版を作る前に欠落参照として拒否されました。この結果は、画像が見えない状態を販売用原稿へ持ち込まず、参照検査で止められることを示します。

失敗したら画像をさらに消すのではなく、旧パスを記録したまま、元画像を戻すか参照を新しい相対パスへ直します。回復後は原稿を閉じて開き直し、画像名を再検索します。一つの画像を複数章が使う場合は全参照を直し、表紙設定も別に確認します。ここで画像そのものを上書きすると、参照修理と内容変更が同時に起きるため避けます。

三章と表紙を完成EPUBから数え直す

正常版の入力は三章、二つの合成挿絵、表紙一枚です。同じ挿絵を複数箇所で使うため、元PNGの枚数ではなく出力上の役割を数えました。生成EPUBを展開すると、cover.pngとp001.pngからp003.pngまでの画像資源がありました。XHTML側にも表紙を含む画像参照4件とalt 4件があり、欠落資源は0件です。Runeのローカル検査はvalid=true、EPUBのSHA-256はd495b57a515828c3d9b306fb1e89e37e5792bf94e8124fe7c92f62fd11e0744eでした。

この四つが一対一で読めることが、参照修理の合格条件です。画像資源が4件でも参照が3件なら、使われない資源が残った可能性があります。参照が4件でも資源が3件なら、どこか一章が欠落を指しています。altの件数も並べれば、参照は直ったが説明が空という別の不備を見つけられます。

「表示されない」を三つの戻り先へ分ける

原稿上で画像が出ないなら相対パスへ戻ります。EPUBのZIP内に画像がないなら、収録対象と表紙設定へ戻ります。ZIP内の資源とXHTML参照がそろっているのに読書画面で出ないなら、そのリーダー名、版、画面方向を記録して表示検査へ移ります。別の層を直すために正常な画像を削除しないことが、復旧を短くします。

今回確認したのは、欠落パスの拒否、四つの画像役割と四参照、欠落0、ローカル構造検査までです。削除警告ダイアログは公開資料上の機能であり、今回の画面実測ではありません。KDP受理、著作権、すべてのリーダーでの同一表示も保証しません。この境界を残したうえで、原稿参照と完成EPUBが一致すれば、画像をむやみに消さず次の表示試験へ渡せます。

参照・格納・表示の診断表を使う

同じ「見えない」でも、結果の組み合わせで次の操作は変わります。原稿の相対パスが存在せず、EPUB検証も欠落を返すなら、原因は参照層です。原稿では開けるのにZIP内に資源がなければ、収録設定または表紙登録を調べます。ZIP内の資源、XHTMLの参照、altがそろうのに特定のリーダーだけで見えないなら、構造を再生成する前にそのリーダーの版と表示設定を記録します。

複数の画像がある本では、最初に失敗した一行だけを直します。たとえば第二章のp002.pngだけが欠けたなら、第一章、第三章、表紙の合格行を固定します。全画像を再挿入すると、直っていた三経路のSHAまで変わり、原因が分からなくなります。修正版を別名で出力し、失敗版の第二章行とだけ比べれば、復旧の説明が短くなります。

削除前の確認では、画像名の検索結果が0件でも表紙登録を忘れないようにします。逆に検索結果が一件あれば、その章を開いて画像の役割を読みます。警告の有無だけに頼らず、参照表を残すことで、アプリの版や操作環境が変わっても同じ判断を繰り返せます。

担当者へ渡す最小記録は、原稿ファイル、画像パス、表紙登録、負の検証結果、修正版EPUBのSHA、四つの参照と資源、未実測のリーダー名です。これらがあれば、次の担当者は警告を見た記憶に頼らず、削除が必要か、参照修理が必要か、表示試験だけが残っているかを判断できます。