Quote:
Originally Posted by DNSB
You could apply hidden to those added epub3 nav.xhtml ToC entries though as far as I can tell from reading the epub3 spec, there is no requirement for every file to have a ToC entry though a spine entry is required.
Looking at the kobolabs epub information kobolabs/epub-spec , Kobo's CMS will add files listed in the spine to the ToC for epub2 files if there is no existing toc.ncx file. For epub3, an existing nav.html (should be nav.xhtml) will be used followed followed by toc.ncx and finally, if toc.ncx does not exist, the ToC will be generated from the spine listing.
Given that the epub2 spec requires a toc.ncx and the epub3 spec requires the navigation document, adding spine files to the ToC should never occur for a standards compliant epub. |
The kobolabs document is the point. It is the only thing that comes close to giving specs for kepubs. It states there must be a ToC entry for each file. It doesn't really matter what other specs say, it is how Kobo have interpreted them and implemented their readers. And that's a lot of the point as well. A kepub is not actually either an epub 2 or a kepub 3. It is Kobo's interpretation of those two spec plus things that they added. Such as ignoring the widows and orphans in the CSS, and the spans wrapping sentences. And requiring that all files in the book are in the ToC.
The Kobo publishing routine make sure this that the generated kepubs match their standards. But, none of the ways of generating kepubs for sideloading make sure of this. I think they are close, but none make sure the ToC is complete.