When converting a manuscript to EPUB, do not stop at “a file was created.” Read the generated navigation links, metadata values, cover reference, and spine order directly. In the measured four-chapter package, the extracted TOC contained four source-ordered links; OPF metadata held concrete title, creator, publisher, language, date, and identifier values; the cover page referenced an existing cover resource; and the spine ran from cover through four chapters to the colophon. Reader rendering remains a separate check.
Prepare one metadata card
Write the intended values before opening the export dialog. This public example uses:
| Field | Example value |
|---|---|
| Title | The Rain Archive |
| Author | Aoi Sato |
| Publisher | Blue Lantern Press |
| Language | Japanese (ja) |
| Writing mode | horizontal |
| Version | 1.0 |
| Publication date | 2026-09-01 |
| Cover | images/cover.png |
These names are reader-facing examples, not the internal placeholder strings used in the recorded run. The method is to compare one card with the metadata stored in the package.
Read four generated navigation links and concrete metadata
The measured manuscript contained C01.md through C04.md with the source headings 序章, 展開, 転換, and 結び. Extracting the generated navigation document returned those four entries in that order. The four body documents appeared as p001 through p004 in the same spine order.
EPUB separates several responsibilities: package metadata, resources, spine order, and the navigation document. A visible-looking TOC alone does not prove the chapters are in the correct spine order.
The extracted OPF held concrete values: title 四章書誌検証, creator Rune 著者018, publisher Rune 出版018, language ja, date 2026-09-01T12:00:00+09:00, and a nonempty UUID identifier. This completes the metadata check on the generated side rather than stopping at configured inputs.
Inspect the cover reference and exact spine order
After choosing a cover, confirm the stored path points to the intended file. A manuscript with zero inline images can still contain one packaged image because the cover is an image resource.
The generated cover.xhtml referenced ../Images/cover.png. That resource existed in the package and carried the cover-image manifest property. The package contained one image and zero missing images. Its spine was cover, title, navigation, p001, p002, p003, p004, and colophon.
Local inspection listed the image-only cover page as text-empty because it contained no body text. That does not mean the image reference was missing; the reference and resource were both directly confirmed. It still does not prove how the cover looks in a reading app, so visual cover review remains separate.
Read the package results by field
The horizontal EPUB produced these values:
| Check | Result |
|---|---|
| Source manuscript | 4 files, 4 chapters |
| Inline source images | 0 |
| Packaged images | 1 cover image |
| Missing images | 0 |
| Navigation document | present |
| Four nav entries | 序章, 展開, 転換, 結び |
| NCX | present |
| OPF metadata | concrete title, creator, publisher, language, date, identifier |
| Cover | image reference present; cover-image resource present |
| Reading sequence | cover, title, navigation, four chapters, colophon |
| Spine count | 8 |
| Local package result | valid=true, no reported issues |
valid=true here means the local structure check reported no issue. It is not retailer acceptance and does not guarantee identical rendering in every reader.
The Rune Studio workflow and its boundary
Rune Studio’s current Mac documentation describes a six-page EPUB wizard for series information, volume selection, manuscript files, file/TOC order, version/date/cover, and final export. It generates an EPUB 3 package including navigation, NCX, and package metadata.
The recorded run set horizontal Japanese output, version 1.0, publication date 2026-09-01, a cover path, and four ordered chapter files. It then exported the package and directly inspected nav, OPF, cover XHTML, manifest, and spine. It did not open the EPUB in a second reader, click the TOC entries, or visually review the cover and metadata display. KDP review, retailer registration, and cross-reader visual equality are outside scope.
Accept the structure before testing appearance
Final checking becomes manageable when you keep five questions separate: Did the generated metadata match the card? Do the four navigation links name the intended chapters? Are p001 through p004 in order? Does the cover page reference an existing cover-image resource? Are missing assets zero? Once those pass, perform any reader-specific visual test you need.
The current Mac app’s EPUB 3 workflow is described on the Rune Studio website.
