using nav.xhtml for TOC
 

(I don't know if it's different with epub 2 since I'm only making epub 3 books.) I create a book with Sigil and when it's finished I generate the table of contents. In the Book Browser I move the nav.xhtml file to the top, just after the book's cover. When I open the book in an e-reader the nav.xhtml is still at the end of the book. If I instead open the book in the Calibre editor and drag the nav.xhtml file to the top in its File Browser and then open the book in an e-reader the nav.xhtml is at the front of the book.

Is there a reason Sigil forces it to stay at the end of the book?

No reason,
because it doesn't force you to.

In fact Sigil puts the HTML TOC at the front (If you use the tool that makes one from the NCX)

Being away from any testing resources, I assume that Sigil's default NAV is not included in the OPF spine (hence why moving it in Book Browser has no effect in your reading app) and calibre DOES include the NAV in the spine. Both approaches are equally correct. I've just never been a real fan of combining the logical NAV document with a visible html toc, myself. but you're certainly permitted to do so within the EPUB specs, so I don't think Sigil will stop you from manually adding the NAV to the spine if you so choose (again: I cannot test that right now. Someone else may need to fact-check me). It just doesn't automatically do it for you.

By default, the NAV document of epub3 books created with Sigil is included in the OPF spine. Sigil supports also epub3 books with NAV documents that are not included in the spine and will display the NAV as the second file in the Book Browser.
If the users changes the position of the NAV document in the Book Browser, it'll be automatically added to the spine.

@hobnail

1. What's your Sigil version and your operating system?
2. Did you also generate a secondary TOC via Create HTML Table Of Contents?

Thanks for the clarification. I would have thought we would have made allowances for the NAV in the spine (otherwise there's no reason for it to be movable). I was basing my guesses off of the symptoms alone. But like you mentioned, I think there may be some confusion between the NAV and secondary html tocs going on here.

Perhaps the OP's epub doesn't include the NAV in the spine, and the secondary Toc that calibre may have created is what's appearing at the end of the book.

1: Sigil 0.9.18, Windows 10.

2: No, I didn't know about that. I was clicking the Generate Table of Contents button, between the Metadata Editor and Spellcheck buttons.

If I use Create HTML Table Of Contents then in the e-reader that one is in the right place but the nav.xhtml is displayed after the last chapter so then I have two displayed TOCs. If I only move the nav.xhtml file up in Calibre's editor that gives me one TOC that's functionally appears to be the same as the one created by Create HTML Table Of Contents while also providing a TOC that the e-reader displays when you click on its TOC button.

Having two TOCs isn't a big problem but I'm wondering why being able to use the nav.xhtml as the displayed TOC (by moving it in Calibre's editor) would be a problem.

In Sigil the nav.xhtml is only movable in the Book Browser but that doesn't change where it's displayed when you look at the book in an e-reader; it's still at the end of the book. There is no secondary TOC. Here's what Calibre Editor's File Browser looks like after dragging the nav.xhtml to the top:

Attachment 175239

I'm also wondering why a secondary TOC is needed since the nav.xhtml file functions as one, after it's moved to the top in Calibre. The epub 3.2 spec says

"But the EPUB Navigation Document is not exclusively for machine processing. Because it is an XHTML Content Document, it can be part of the linear reading order, avoiding the need for duplicate tables of contents. Content which is only destined for machine processing, such as page lists, can be hidden from visual rendering with the hidden attribute."

https://www.w3.org/publishing/epub3/epub-packages.html

You definitely can use the NAV document as a TOC. (For a proof of concept, see this simple MR EPUB3 book.)
Maybe your e-reader always displays the NAV document at the end of a book?
To test this open the EPUB3 book that I've linked to with Sigil, move the NAV document after the cover, save the book and open it with your e-reader.
If it displays the NAV document at the end of the book, it's the e-reader that causes this problem.

Could it be linear="no" attribute on the nav in the spine.

eReader displays in the order described in OPF's spine.
Is nav.xhtml at the bottom?

When nav.xhtml is used as a document table of contents, please arrange in order by spine.
If you have another document table of contents and you do not want to display nav.xhtml, you do not have to write it in spine.
Even if linear = "no", it will not be displayed.
However, linear = "no" is used for auxiliary display sheets such as popups.

When nav.xhtml is used as a table of contents page, it cannot be decorated.
So it is recommended to create another document table of contents and hide nav.xhtml.

Of course, you cannot link to nav.xhml in a toc landmark entry, if it's not in the spine. However, if it is in the spine, you can link to it. As for linear=no I don't know of a single epub2 app that actually honors it, which is not at all surprising, because the epub2 specs don't strictly require apps to hide spine items with a linear=no attribute.
If you're interested in creating epub2-compatible epubs for Amazon KDP, you can take advantage of this fact and move the nav document after the cover and add a linear=no attribute and toc landmark/guide items. Since all major epub3 apps honor linear=no, the nav document will only be shown as an HTML TOC in epub2 books.

I disagree. IMHO, an additional HTML TOC with the same TOC links as the NAV document would be redundant.

I haven't created it with epub2, so I don't know its specifications.
Adjustments are required to use both epub2 and epub3.

However, the table of contents page may have italics, bold, and other text decorations.
If we want to reproduce it, we need to prepare it separately.


I will return to the question.

Spine cannot be rewritten by moving files with sigil's book browser.
When moving with the calibre book browser, it is automatically rewritten.
Does that mean that?:chinscratch:

It does seem to be what they were saying. It's absolutely untrue, however. Reordering files in both programs reorders the spine.

I've been working with some files in Sigil and Calibre, and it seems like Sigil now automatically puts the nav.xhtml in the spine, and at the very beginning of the book. Is this a new behavior? Is it intended? And where is it best practices to put the nav.xhtml in an EPUB3 file, because I'm pretty sure I don't want it at the very beginning.