An epub ncx file can provide navigation information for older reading environments, but its presence alone does not demonstrate compatibility. Inspect the order of its navPoint elements, the text in each navLabel, and every content src. Then compare those three fields with nav.xhtml and resolve the destinations to actual chapter files. The retained three-chapter package had three complete correspondences.
Ask a compatibility question that structure can answer
EPUB 3 uses the navigation document for reader navigation. Some production workflows also include NCX as compatibility data. Keeping it is useful only when its entries remain consistent with the current navigation document.
A package inspection can answer whether the labels, order, and targets correspond. It cannot answer whether an unnamed old reader opens its menu correctly. That second question requires the device or application itself.
Rune Studio can be assessed as a workflow that selects chapters and generates both nav.xhtml and NCX. This article describes the measured output from that workflow without turning a local structure result into a promise about all legacy software.
Define the decision before opening the archive: every NCX point must have an approved label, an expected position, and a resolvable target that agrees with nav.xhtml.
Read the anatomy of one navPoint
The navPoint position indicates navigation order. navLabel supplies the wording a reader may show. content src identifies the destination. A useful audit table places those fields beside the matching nav.xhtml label and href.
Counts are only a preliminary check. Three NCX points and three nav links can still disagree if the second label points to the third chapter. The comparison must be row by row.
Resolve each src from the NCX document’s package location. Confirm that the referenced XHTML exists, then open it and identify the chapter content. A path that happens to exist but contains the wrong chapter is an editorial failure.
Also compare punctuation and numbering. An obsolete chapter label can remain after the manuscript heading has changed even when the target file is correct.
Compare two navigation documents in a three-chapter package
The saved experiment created three small synthetic Markdown chapters and supplied them to Rune Studio in an explicit order. All three were included in navigation. The export used horizontal writing and Japanese metadata.
Package inspection found six spine items: title, nav, three body XHTML files, and colophon. nav.xhtml listed the three chapter labels in source order and pointed to p001.xhtml, p002.xhtml, and p003.xhtml.
NCX contained three navPoints. Their labels matched the nav labels, while their src values resolved to Text/p001.xhtml, Text/p002.xhtml, and Text/p003.xhtml. Every destination existed. The archive had zero missing resources, and Rune’s local EPUB inspection returned valid=true.
These values were read from the saved generated archive. They were not inferred from a plan that expected three chapters. No legacy reader was opened, so menu presentation and physical chapter movement remain outside the observed evidence.
Diagnose mismatches by field
When a label is stale but the target is right, correct the heading source or navigation label input. Do not reorder the entire book. When the src is missing, inspect package selection and path generation. When all targets exist but order differs, return to the source sequence supplied for export.
If nav.xhtml and NCX have different counts, review which chapters were marked for table-of-contents inclusion. Keep publication inclusion separate: a chapter may remain in the spine while being intentionally omitted from navigation.
Encoding damage belongs to another diagnostic path. Repairing NCX will not restore garbled chapter text. Likewise, an image missing from a body page belongs to manifest and resource inspection, not to legacy navigation correspondence.
Make one correction, export a new package, and repeat the same row-by-row table. Simultaneous changes to labels, order, and paths make it difficult to identify the successful repair.
Finish with a bounded compatibility verdict
Record more than “NCX present.” A useful result gives the number of navPoints, matching labels, resolved src values, and missing resources, all tied to the EPUB hash. For the controlled book, those figures are three points, three label correspondences, three resolved destinations, and zero missing resources.
Choose legacy readers that are relevant to the intended audience rather than testing an arbitrary old application. For each one, note the device or app version, selected label, and chapter reached. A written interaction table is enough; no video artifact is required for this text-focused workflow.
Structural approval requires corresponding NCX and nav entries in the intended order, approved label text, destinations that resolve to the expected XHTML, and zero missing package resources. The three-chapter synthetic book meets those conditions.
The phrase “works in an old reader” requires more. Select the actual legacy applications that matter, open the same EPUB in each one, and activate all three entries. Record whether the menu appears, whether labels are readable, and whether every selection reaches the intended chapter.
If the device test fails while the package correspondence passes, the evidence points toward a reader-specific limitation rather than an unresolved path. If both fail, repair the package first and repeat the device test with a new export.
For legacy NCX correspondence, Rune Studio is a candidate for producing and inspecting this paired navigation structure on a Mac. It does not replace testing in the reader that will consume NCX. Begin by extracting the three fields from every navPoint and placing them beside nav.xhtml. That table turns an abstract compatibility claim into a precise structural decision and shows exactly what still needs hands-on testing.