「パスが直った」と「画像が表示された」は別の合格にする
ファイル移動後にEPUB画像が表示されなくなった場合、修復完了には二種類の証拠が必要です。第一は、画像の新しい所在と原稿中の参照が一致し、旧パスが0件になったこと。第二は、修正後にEPUBを再出力し、対象の閲覧環境で画像表示が回復したことです。第一だけを満たしても「表示された」とは結論づけません。
今回の記事固有Stage 4で確認したのは第一のパス整合だけです。3原稿4参照を明示的に書き換え、旧パス0件、新パス4件を確認しました。statusはpartialのままです。自動修正の実行、EPUB再出力、リーダー上の表示回復は確認していないため、タイトルの疑問への現在の答えは「原因候補をパス不整合まで狭められるが、表示修復済みとはまだ言えない」です。
事故後は表示症状から二段階の証拠表を作る
移動前の予防台帳ではなく、すでに「表示されない」という症状がある時点から始めます。修復記録は次の二段階に分けます。
| 段階 | 合格条件 | 今回の状態 | 不合格時の次の調査 |
|---|---|---|---|
| パス整合 | 画像が新位置に存在、旧0、新4、内訳1・1・2 | 一部確認済み | 所在、ファイル名、参照更新へ戻る |
| 表示回復 | 再出力したEPUBで対象画像を表示 | 未確認 | 画像破損、形式、CSS、package登録、閲覧環境を調べる |
この二段階を一つの「修正成功」にまとめないことが、事故後の記事としての中心です。パス整合を通過しても表示されなければ、同じ参照書き換えを繰り返さず、別原因へ進めます。
3原稿4参照の偏りをパス整合の標本にする
標本の画像はimages/map.png、移動先はassets/maps/map.pngです。開始値はC01.mdに1件、C02.mdに1件、C03.mdに2件、合計4件でした。1章だけ参照が重複するため、総数だけでなく原稿別の1・1・2件も保持します。
パス原因として扱う前に、新しい保存先に画像があるか、ファイル名、拡張子、大文字小文字が変わっていないかを確認します。画像自体が欠落または破損していれば、参照文字列の修正では表示は戻りません。
実測したのは4件の明示更新であり自動修正ではない
Stage 4では、移動前に3原稿の参照利用箇所を取得し、images/map.pngからassets/maps/map.pngへの変更を確認しました。画像を移動した後、4箇所を明示的に書き換え、旧パスと新パスを再検索しています。
結果はreferences_before=4、reference_files_before=3、rewritten_occurrences=4、old_path_matches=0、new_path_matches=4です。新参照の内訳はC01.mdが1件、C02.mdが1件、C03.mdが2件でした。開始時の参照分布を新しいパスで回収しています。
参照更新計画のplanned_filesは0でした。したがって、この結果を「画像を移動しただけでRune Studioが4件を自動修正した」とは表現しません。実測の操作は、影響箇所を数えた後の明示的なrefs rewriteです。
パス整合が合格しても表示回復の証拠は空欄にする
旧0件・新4件は、原稿の参照文字列が新しい所在へ揃ったことを示します。EPUB内部に画像が収録されたこと、CSSで非表示になっていないこと、画像形式が閲覧環境で扱えること、実際に画面へ表示されたことは示しません。
本来の表示回復確認では、修正後の原稿からEPUBを再出力し、対象画像がpackageへ入ったことを構造検査で確認し、さらに問題が出た閲覧環境で同じ箇所を開きます。今回はその操作を行っていません。したがって、表示回復欄は未確認のまま残し、パス整合の合格で埋めません。
partialのまま別原因へ進める条件を決める
パス整合後も画像が表示されない場合は、旧パス検索へ戻り続けるのではなく、次を別々に調べます。
- 移動先の画像ファイルが壊れていないか
- 画像形式が出力処理と閲覧環境の対象か
- EPUB内部のmanifestと本文XHTMLに資源・参照があるか
- CSSが画像を隠していないか
- 問題が特定のリーダーだけで起きるか
これらは今回のStage 4では除外していません。Finderやクラウド同期による外部移動の自動追従、共同編集、ワークスペース外の変更も未確認です。未確認項目を「パスが直ったから問題なし」と閉じないでください。
Rune Studioの自動更新は公開仕様と実測を分ける
Rune StudioのMac版では、ワークスペース内でファイルを移動または名前変更したとき、対応するMarkdown系原稿の相対画像・リンク参照を更新できると公開されています。対象はtxt、text、md、markdownで、../を含む相対パスにも対応します。外部URLとページ内アンカーは変更しません。
この公開機能は、移動後の参照切れを減らす製品上の候補です。一方、今回のStage 4はCLIでの明示書き換えです。公開機能の存在を、今回の4件が自動で追従した証拠や、表示が回復した証拠として使いません。
結論：現在確認できたのはパス修正まで
今回の専用標本では、3原稿4参照を1・1・2件の分布ごと新パスへ揃え、旧パス0件を確認しました。これはパス整合段階の結果です。EPUB再出力とリーダー表示を実施していないため、画像が表示されない問題を修復済みとは判定しません。
事故後の完了条件は、パス整合と表示回復の両方です。第一段階を通過しても症状が残れば、パス以外の原因へ進みます。今回のpartialは失敗を成功へ言い換えた状態ではなく、「参照は修正済み、表示は未確認」という次の調査位置を示します。
