[KevinH]

This is due to a recent change in epubcheck. The meaning of using linear="no" on the spine itemref in the opf is not clear from the specification. Some e-readers do not show anything that has linear="no" whereas other ereaders do. So to force the issue, epubcheck wants an external link to anything listed as "linear="no" from some other document in the spine without the linear="no".

But this is a silly restriction that should never include the nav.xhtml as it is machine parsed and presented to epub reader by the e-reading software always. No external link to it is needed. But epubcheck treats the nav like every other xhtml file.

The only solutions are:

1. remove linear="no" from the spine itemref entry for the nav. But then the nav will be seen as an xhtml toc and be part of the reading order. You should then remove any xhtml TOC and use the nav instead and add to the nav css stylesheet to make it look like what you want.

2. remove the nav entry from the spine completely. But this can generate an error since the nav can only link to things in the spine, but some navs may internally link back to itself (ie. use just a fragment). So you must remove any internal link in the nav.xhtml to itself on the nav landmarks.

3. Add a small footnote with a link to the nav from the xhtml table of contents (or any other place that it might makes sense). But then you must have an xhtml table of contents to put the link in.


Personally since the nav is always accessible to the end user just like the old NCX was, they should not be applying this rule to the nav in epubcheck. I argued with them about it but got nowhere.

When another xhtml toc exists in the epub I typically just use approach 3 since it is the easiest. If no xhtml toc exists, then I use approach 1.

I have used approach 2 but in my opinion that hurts the nav by making it less informative and less accessible since not all landmarks are included.