For epub nav, an EPUB navigation table of contents passes only when every visible label appears in the intended order and every href resolves to the correct XHTML file inside the package. The presence of nav.xhtml, or even the expected number of links, is not sufficient. In the five-chapter test retained for this article, five labels were paired with p001.xhtml through p005.xhtml, and every package target existed.
Why a correct count can still hide a broken table of contents
Suppose a book has five chapters and nav.xhtml has five anchors. Chapter Two can still point to Chapter Three while the count remains correct. Readers experience the error as a misleading menu, not as a missing link. That is why the acceptance record needs one row per label-target pair.
Before export, make a source table with three fields: approved chapter position, approved chapter title, and source filename. If some content belongs in the publication but not in the table of contents, record publication inclusion and navigation inclusion separately.
This article focuses on reachability in the current navigation document. It does not use the visible tree in an editor as the final result, and it does not treat legacy NCX behavior as proven merely because an NCX file is generated.
Build a fixture that isolates navigation
The saved experiment used five small synthetic Markdown files, each with one distinctive heading. They were supplied to Rune Studio in an explicit order, and every chapter was included in the table of contents. Images and complicated inline markup were intentionally omitted so that navigation remained the only variable.
The exported package contained eight spine items: title, nav, five body XHTML files, and colophon. Package inspection found five nav links and five NCX points. No manifest resource was missing, and Rune’s local EPUB inspection returned valid=true.
This is direct evidence from the generated archive, not a copy of the planned chapter count. It is also a structural test. No third-party reader was operated, so menu design and device-specific navigation behavior remain outside the observed result.
Audit the label text as editorial content
Readers choose a destination by its label. Compare each nav label with the approved heading rather than with an internal filename. Check numbering, punctuation, capitalization, and any editorial changes made late in production.
The controlled output contained STUDIO-410 検証章1 through STUDIO-410 検証章5 in order. Those synthetic labels matched their source headings. A real manuscript must be compared with its own approved title list; the test does not imply that every heading is updated automatically in every workflow.
When only a label is stale, return to the source of the chapter title or the navigation selection. Do not reorder the entire book or re-encode the text. Make one targeted correction and export a separately named result.
Resolve each href inside the package
An href is useful only if it reaches a real file. Resolve it relative to the location of nav.xhtml, confirm that the target exists in the EPUB, and open that XHTML to verify the expected chapter text. A plausible filename is not proof of a valid destination.
The five test links resolved in sequence to p001.xhtml, p002.xhtml, p003.xhtml, p004.xhtml, and p005.xhtml. The manifest also had zero missing resources. Together, the link resolution and manifest check cover both the navigation reference and package inclusion.
If a target is missing, inspect the source selection and packaged path. If the target exists but contains the wrong chapter, inspect the input order. These are different failures, and combining their repairs makes the result harder to audit.
Diagnose order errors without changing the manuscript
Compare the approved position column with the order of nav anchors. If Chapter Four appears before Chapter Three, verify the order in which sources were supplied to the EPUB builder. Do not rename every chapter until the order source is understood.
Next compare nav.xhtml with the spine. A chapter can be in the reading order while intentionally absent from the navigation list. Such a difference is not automatically a defect. The editorial table determines whether the omission was intended.
Finally compare nav with NCX as a consistency signal. The saved five-chapter output gave the same labels and order in both documents. That observation does not guarantee behavior in a legacy reader, but a mismatch would be a useful reason to revisit generation settings.
Keep current navigation separate from NCX compatibility
EPUB 3 uses the navigation document as a publication component. NCX may also be supplied for compatibility in some workflows. This guide approves nav.xhtml by its labels, order, and resolved links. Another test must operate target legacy readers before claiming that their menus work.
The same boundary applies to visual appearance. Structural reachability does not prove that a reader displays indentation, truncation, or nested navigation in a particular way. If those details matter, use the same five destinations in a device test and record the actual interaction.
Make the reader handoff decision
The release checklist for navigation reachability should show the approved number of links, the exact label for each row, its intended order, its resolved XHTML target, and the package’s missing-resource count. A single total such as “five links” cannot replace the row-by-row comparison.
Rune Studio is a candidate when an editor wants to select chapters, generate nav.xhtml and NCX, and inspect the resulting archive on a Mac. The verification method also works with EPUBs created elsewhere. Start by listing the approved headings and source files. After export, place the five observed nav rows beside that list and resolve every destination before giving the book to readers.