Quote:
To test DNSB's theory that even an internal link from a non-linear resource (the nav) back to itself is enough to fool the epubcheck test (why a link from a non-linear resource to itself would make any difference is beyond me).
I changed the Sigil User's Guide nav landmarks section to to add an internal back link (see the last li I added below):
Code:
<nav epub:type="landmarks" id="landmarks" hidden="">
<h1>Landmarks</h1>
<ol>
<li>
<a epub:type="cover" href="Text/cover.xhtml">Cover</a>
</li>
<li>
<a epub:type="bodymatter" href="Text/introduction.xhtml">Text</a>
</li>
<li>
<a epub:type="toc" href="Text/toc.xhtml">Table of Contents</a>
</li>
<li>
<a epub:type="toc" href="#toc">Nav Table Of Contents</a>
</li>
</ol>
</nav>
And I removed the link from the xhtml toc to the nav I had added just to make it pass, and sure enough, it passes epubcheck!
So DNSB's theory is right! We can prevent the whole epubcheck bug from hitting by just adding an internal link from the nav landmarks back to the nav table of contents and that fools the code into thinking that all non-linear resources are reachable from some linear resource.
|
So that looks like the most simple answer for the moment. Are there any adverse consequences from having two toc type references in the landmarks?
----------
I had been trying to make a link from the HTML toc to the nav but got the error that the nav.xhtml could not be found.
The answer to that was remembering what Kevin had said back in post #17 -- that nav.xhtml was not in the Text folder. It requires referencing in the link as ../nav.xhtml. This I verified by opening the User Guide in Sigil.
Strangely, though, Sigil shows the nav.xhtml in the Book Browser window as being the last entry in the Text folder. Closing the Text folder makes the nav file disappear from the Book Browser listing.
Wouldn't it be less misleading for the Book Browser to display the nav.xhtml file below the Misc folder and next to the content.opf?