In an image-rich ebook, inline figures and the cover must not be treated as interchangeable “image files.” For how to create an EPUB ebook with images, resolve each chapter's relative Markdown path, then verify the cover's separate metadata role. A correct total with the wrong roles is still a packaging error.
Three inline figures plus one cover
The controlled four-chapter sample referenced three inline PNGs and assigned one additional PNG as the cover. Package inspection returned four images, eight spine entries, four nav links, four NCX points, and valid=true. The image count therefore matched the explicit asset plan: three content figures plus one cover.
After moving an asset folder, copying a same-named file back to the old location only hides the broken organization. Repair chapter-relative paths for inline images and update the cover assignment through its own route. Re-export under a new filename so that the corrected package can be compared with the failed one.
Acceptance requires every manuscript reference to reach a real file, the cover to carry its cover role, and the package asset count to match the inventory. This check does not decide image rights, retailer ingestion, or cropping behavior in every reader.
Draw the asset map from each chapter
A relative path is meaningful from the file that owns the reference. If chapters/01.md calls assets/scene-a.png, the handoff sheet should name that chapter, the literal source path, and the intended asset. A workspace-root view can make a path look plausible even when the chapter resolves it somewhere else. Before a move, count the old references. After the move, require zero old references and the planned number of new ones. Restoring a same-named copy at the abandoned location merely hides the broken map.
Give the cover its own route
The cover is selected through the book setting, whereas each inline figure is reached from manuscript markup. Treating the first illustration as a cover because it looks suitable does not establish its package role. In the measured specimen, one cover and three inline PNGs were intentionally separate. That distinction explains the package total of four images and makes a later replacement local: edit the page-five cover assignment for a cover change, or edit a chapter reference for an illustration change.
Plan counts before pressing Export
The four-chapter plan is a compact control document. It predicts four navigation links, identifies three inline calls, and records one cover candidate. The observed archive returned eight spine items, four nav links, four NCX points, and four images. Spine items include generated reading-order documents, so eight must not be compared directly with either the chapter count or image count. Every number has a named source and a matching inspection field.
Rehearse the relocation failure on a copy
To test recovery without risking a manuscript, move one synthetic asset and leave its old reference untouched in a duplicate. The expected failure is a missing target, not a vague visual impression. Repair only that reference, export under a fresh filename, and reopen the archive. Do not paste the missing file into the finished EPUB: such a patch bypasses the project source and will disappear on the next export.
Read the delivered archive, not the last screen
An export-complete message proves that a process ended; it does not enumerate the files inside the container. The durable check is the reopened EPUB. For this specimen, local inspection reported valid=true, image count four, and both navigation formats present. Preserve the EPUB hash alongside the inventory so a reviewer can tell which build produced those values. A changed hash is not automatically bad, but it demands a new inspection record.
Separate structural and editorial acceptance
Package inspection cannot decide whether the illustrations are licensed, whether alternative text is useful, or whether a storefront will crop the cover attractively. Those questions need their own owners and evidence. Structural acceptance means every planned reference resolves, the cover has the cover role, and the archive contains the four expected assets. Editorial acceptance follows after visual, rights, and accessibility checks.
The safest handoff is therefore a small map: three chapter-to-image routes, one page-five cover route, the measured package counts, and the archive digest. That map remains useful after folders move because it tells the next operator what to repair and what not to touch.
A final review should expand the EPUB and map every packaged resource back to one of the four inventory rows. Export may rename or transform an image, so a byte-for-byte comparison is not always the right test; record the manifest identifier, media type, dimensions when relevant, and owning chapter. For the three inline figures, follow the XHTML reference. For the cover, follow the cover relationship. This last mapping catches the subtle case in which four files exist but one figure has been substituted for the cover.
If only one row fails, preserve the other three accepted routes. Repair the owning source path, generate a new archive, and repeat the inventory on that archive's digest. This narrow loop keeps evidence attributable. The result is a reproducible image-rich package check rather than a broad claim that every reading system will display the book identically.
The inventory should travel with the project, not only with one export. If a chapter moves again, update its row before packaging and compare the predicted four roles with the next archive. A reviewer can then distinguish a deliberate cover replacement from an accidental duplicate asset without relying on filenames alone.
For this article, image-rich EPUB creation means preserving three chapter references and one independently assigned cover through the reopened package.
