An epub navigation document tells readers which parts of a publication are offered as navigation choices. Publication inclusion and table-of-contents inclusion are separate decisions. In the six-chapter experiment retained for this guide, all six chapters remained in the spine while Chapters One and Six were excluded from nav.xhtml. The navigation document and NCX consequently listed only the four middle chapters.
Model the publication as two overlapping sets
Some content belongs in reading order without needing a table-of-contents entry. A short preface, a title page, or a colophon may be included but omitted from the primary chapter list. Removing its navigation entry does not necessarily remove its XHTML from the EPUB.
Create an editorial table with a publication column and a navigation column. The publication column records reading order. The navigation column records whether the item should appear, the approved label, and its destination. This table prevents a missing menu entry from being mistaken for a missing chapter.
EPUB 3 defines a navigation document as a publication component. Rune Studio can be evaluated as a Mac workflow that selects chapters and generates nav.xhtml and NCX. The standard role and the product operation should be described separately.
The focus here is the distinction between inclusion and reader guidance. Detailed anchor authoring, encoding repair, and retailer menu appearance are different questions.
Use a controlled exclusion to reveal the distinction
Six synthetic Markdown chapters were supplied in explicit order. Chapters One and Six were marked as excluded from the table of contents, while all six remained selected for the publication.
The exported spine had nine items: title, nav, six body XHTML files, and colophon. This directly confirms that the two excluded navigation entries did not delete their body files.
The generated nav.xhtml contained links for Chapters Two through Five. NCX contained the same four labels and destinations in the same order. Every href and src resolved to an existing XHTML file, the package had zero missing resources, and Rune’s local inspection returned valid=true.
These findings come from the saved package. No third-party reading system was operated. How a particular app styles, truncates, nests, or exposes those four labels remains unobserved.
Read the generated document in three passes
First review the visible labels. Compare them with the approved editorial table, including numbering and punctuation. A correct destination with an obsolete chapter name can still mislead a reader.
Second review order. The four links should follow the intended navigation sequence, which may or may not include every publication item. Do not use the count alone as approval.
Third resolve every href relative to nav.xhtml and open the target. Confirm that the XHTML contains the intended chapter. A filename that exists but holds different content is not a valid editorial destination.
If a label is wrong, return to the approved heading source. If an item is unintentionally absent, adjust navigation inclusion. If the body itself is missing, inspect publication selection. Those failures have different rollback points.
Apply the distinction to editorial decisions
The six-chapter example represents a deliberate design: readers can move through the four central chapters from the navigation menu, while the opening and closing material remain in reading order. Whether that is a good design for a particular book depends on its audience and content, not on a universal rule.
Record why each omitted item is hidden from the table of contents. A reason such as “short unnumbered preface” is more useful than an unchecked box. During later revisions, the editor can distinguish a deliberate omission from an accidental one.
Comparing nav.xhtml with the spine also helps diagnose reported problems. If the reader reaches hidden material by normal page progression, the publication may be correct even though the menu omits it. If the spine lacks the file, the issue is broader than navigation.
NCX correspondence is a useful structural check, but it does not prove behavior in a legacy reader. That claim requires operating the target reader.
Approve the document within measured limits
In a team review, let the structure editor freeze the two expected sets and let the export reviewer add the observed spine and nav values. This prevents one person’s memory from defining both intention and result. When a single row changes, recheck its neighbors as well, because an insertion can shift order without changing the total count.
Revised editions deserve a fresh navigation table. A newly added chapter creates three decisions: whether it belongs in the publication, whether it deserves a menu entry, and what label readers should see. Copying an old nav file and increasing its count can leave a correct-looking link attached to the wrong body file.
Some retailers and reading applications build additional menus from several metadata sources. This local package result does not predict those interfaces. If a specific storefront menu matters, complete the structural approval first, then submit or sideload the exact EPUB and document what that service displays.
The structural acceptance rule for publication-versus-navigation control is: the spine matches the publication table, nav labels and order match the navigation table, every destination resolves to the intended XHTML, and the package has no missing resources. The retained six-chapter fixture satisfies that rule.
Rune Studio is a candidate for editors who want to make these two selections and inspect the generated EPUB on a Mac. Visual menu presentation, retailer acceptance, and device interaction require separate checks. Start by marking each manuscript item twice: once for inclusion in the book and once for inclusion in navigation. That simple distinction makes the purpose of nav.xhtml concrete before any export is generated.