EPUB3 with NAV doc and HTML TOC

[democrite]

Hello,

From what I recall, when it comes to publisher provided EPUB3s, most of them have a separate NAV doc plus XHTML table of contents. I'm not sure how most are dealing with such; I prefer to not see the NAV when scrolling through an EPUB, whether at beginning or end. The situation is common enough, perhaps there could be a built-in option to combine them and make the NAV text hidden? Some publishers provide files as such but I think it's fairly rare.

I haven't checked if there is such a plugin. Since it's common enough at least with files provided as such, I think showing both is not very elegant, and having it built-in rather than as a plugin (either way at first), as I would perform such with pretty much every EPUB3, skipping the plugin dialog and having it done with one click would be very nice.

Perhaps with converting to EPUB3, there too could someday be an option to add it to the XHTML toc if one exists. Certainly any of the above I could manually do, though as editing could be many long hours of clicking and mouse movement and typing, any reduction such that it just works and is easy via one command, just as with any other built-in functions, I think would be ideal. I have perhaps thousands of EPUBs as such and merely being able to open them, select some command, save, then close would be terrific.

[JSWolf]

Originally Posted by democrite

Hello,

From what I recall, when it comes to publisher provided EPUB3s, most of them have a separate NAV doc plus XHTML table of contents. I'm not sure how most are dealing with such; I prefer to not see the NAV when scrolling through an EPUB, whether at beginning or end. The situation is common enough, perhaps there could be a built-in option to combine them and make the NAV text hidden? Some publishers provide files as such but I think it's fairly rare.

I haven't checked if there is such a plugin. Since it's common enough at least with files provided as such, I think showing both is not very elegant, and having it built-in rather than as a plugin (either way at first), as I would perform such with pretty much every EPUB3, skipping the plugin dialog and having it done with one click would be very nice.

Perhaps with converting to EPUB3, there too could someday be an option to add it to the XHTML toc if one exists. Certainly any of the above I could manually do, though as editing could be many long hours of clicking and mouse movement and typing, any reduction such that it just works and is easy via one command, just as with any other built-in functions, I think would be ideal. I have perhaps thousands of EPUBs as such and merely being able to open them, select some command, save, then close would be terrific.

NAV is part of the ePub3 specification. You have to have it to have a valid ePub3. What you don't need is the HTML ToC. That's not part of the specification.

When scrolling though an ePub3 eBook, you won't see the NAV ToC. You will only see the NAV ToC when you use the option to view the ToC. ion the software you are using. Think of the NAV ToC as an external file that only gets called when you call for it.

[KevinH]

Jon is correct. And again requests for new features should be labelled as such and should include how this feature request might benefit others.

It sounds like you just want to use Sigil to "fix" a pet peeve in your current ebook library as quickly and easily as possible and want Sigil to be adapted for your use. You even ruled out plugins for some reason.

To be frank, a "feature" request like this is never going to be accepted by me. There is just no general need for such a "feature".

My suggestion is to get a real epub3 reader that interprets linear="no" the way you want it to.

[Doitsu]

Originally Posted by democrite

I prefer to not see the NAV when scrolling through an EPUB, whether at beginning or end.

Simply remove the nav doc reference from the spine.

Originally Posted by w3.org

As a conforming XHTML content document, EPUB creators MAY include the EPUB navigation document in the spine.

[DNSB]

For what it's worth, I just checked through 49 epub3 ebooks. In all but one, the nav.xhtml was also doing duty as the user table of contents. The 49th book had the nav.xhtml at the start of the book and a separate table of contents at the end.

[DiapDealer]

Easy enough to achieve manually. Certainly a plugin candidate for someone. Either way, Sigil's not a bulk editor. So time saved modifying 1000s of epubs is always going to be negligible.

[democrite]

I am aware of the purpose of the NAV doc.

My request is perhaps from a mistsken understanding of how to have a nav doc but not have it shown when navigating the book.

Linear no was what I used to use but epubcheck now complains of no link. I could add one but its really not needed and I consider it inelegant.

Not having it in the spine is perhaps preferred yet Sigil from what I recall often auto adds any missing XHTML file to the spine, such that I need to often reverify if it has been readded. Perhaps that's a main issue. Forgot if there's an option; I haven't checked recently.

Thus I thought if nav and XHTML toc were combined, it'd be a way around such. Yet not the preferred method; I merely thought it was a possible workaround.

As for having separate NAV and XHTML TOCs. in contrast to a previous mention, nearly all epubs I read are designed as such, though all of them are from academic publishers.

The main issue I have been struggling with is having the NAV toc fully work with Apple Books. Once for some reason, for all my epubs, toc entries were not selectable in ios/ipados unless each entry had an anchor and didn't just point to a file, so I added an id to the body tag and had to do that for all my epubs, having had to do such for years. I'm not sure if that quirk is now fixed or why some epubs were as such, and others not.

The current true issue is I'm having trouble getting pagelist numbers to show up in Apple Books. Ok ok macOS not on iPhone iPad. This started maybe some months ago with some iOS update.

My typical workflow is to normalize, convert to epub 3 if not already, make a backup of the nav e.g. as nav2 that isn't in the spine or defined as nav but just as backup (just in case I mess up something in later edjting), create a new toc containing all H2+ headers, create a XHTML toc for such sections but have such not defined as the XHTML contents, copy such to the original XHTML toc such that it has the original formatting yet contains all sections of the book (tformattinlcontain only part and chapter headings), then copy back thformattinl nav.

I also rename all files to have part and chapter number. I do such since it makes it easier for regex replacement such as adding links to all headers that return to the toc, for easy navigation. Such also makes editing much quicker, for example so I know this or that file is chapter X in part X, appendix X, etc.

Somewhere along that process, despite many unmodified epubs showing page numbers fine in iOS Books, none of mine now do despite passing epubcheck. I tried but can't figure out why.

[KevinH]

If you can create a sample epub that shows the issue with page numbers and post it here, I would be happy to test it in Apple Books on my ipad, and in the BlueFire Reader on my ipad to see if I can figure out what is going on.

[democrite]

Thank you very much Kevin. The page number issue really is only with iOS/iPadOS 16+; I'm not sure if it started with that or a later version. TOC entries seem also unselectable still with that if there's no anchor but merely a XHTML destination. Maybe Sigil does something in particular or I am doing something. I tested various other readers such as BlueFire, Maple, and other and they're all ok. Books macOS is also fine with showing page numbers.

I'm not sure at the moment when I can get around to making a test file, but I can PM a modified commercial EPUB that shows such an issue, if that's ok. I've tried looking at other unmodified commercial EPUBs and trying some of the NAV element attributes but I can't figure it out.

[KevinH]

So when unmodified did the commercial epub properly showed page numbers in iOS/ipad Books?

When unmodified did the toc links work without fragment identifiers in iOS/iPad?p Books?

Then you modified the commercial epub and then both stopped working?

Unlike most epub readers, Books on ios, open the epub the very first time they are added, identifying and caching cover images, embedded fonts, and etc. This could include toc and page numbering.

So if you modify any epub you must first fully delete it (and that cache information) from your Books library *before* adding the modified book back to the Books.app. Otherwise the old cached information is used and not properly recreated.

[democrite]

Yes a few unmodified EPUBs I've tested work fine on iOS 16 with both page numbers and toc links without anchors. Before with iOS 15 and previous, all worked fine though I did for some reason need those fragment identifiers.

Any modified EPUB I haven't added to Books until after all changes. I am aware of cache issues and other. Really I'm not sure what is going on. Some quirk with iOS 16 that is different from macOS Books.

Maybe I'll test out some things. I use dashes in file names. Within the EPUB, I typically rename toc.xhtml to contents. That and a backup of nav typically named nav2, both remain unused in the spine or defined as nav but merely I use the former to make as mentioned H2+ links that I add to the original XHTML toc and the latter as a nav backup during the process. Maybe books gets confused as such. For landmarks, commercial epubs I've seen sometimes from what I recall have no toc defined plus isn't listed in the ncx as toc, or sometimes maybe such is. I've tried various changes and haven't figured out such yet.

[democrite]

I haven't compared carefully but one that worked fine, the nav landmarks section contained from what I recall all files except the xhtml toc.

To be clear, all books, many hundreds, previously added before iOS 16 they also stopped working, at least the ones I've tested. Maybe there is something now unique to iOS/iPadOS, or maybe it's a bug, and maybe there's some clue or spec in the Apple Books Asset Guide, something that makes commercial ebooks I've tested work fine since perhaps many are submitted to the Apple Store and have something different about them. Who knows, various testing and haven't figured it out. bug maybe, or if it's something particular to Apple Books in now how it works, and if it is something that Sigil doesn't add, if, then perhaps something could change to improve compatibility given that Apple Books is so common.

[KevinH]

Unfortunately, Apple Books is not a compliant epub3 reader and has been pushing their own extensions from the very start. Based on ebook sales figures they are a very minor player in the industry. When you add to the fact that their DRM was never broken, many users stayed away as there was no way to move their purchases to another platform (ie from Apple to Linux or Android).

If you want an epub3 compliant reader on iOS then use the BlueFire Reader. The Kobo reader for kepub works reasonably well too.

If you want to pm me a link to an epub3 that is unmodified and works in iOS Books alongside a modified version that does not work, I would be happy to take a look. But short of that, Sigil's goal is to make epub3 compliant epubs, not necessarily Books compliant ones. Complain to Apple but be prepared for no fixes or changes probably ever.

KevinH

[democrite]

I think the drm has been cracked but I haven't tried such.

I am aware of Books extensions for fixed layout and perhaps other though I am not referring to that. I think it's possible that merely Apple is maybe interpreting the spec in some places differently in cases of who knows, maybe where there is ambiguity or for what is optional. That's just a guess; it could still just be a bug.