epub toc blank (sigil, ibookstore)

Hoping someone can shed light on a possible obscure bug!

Scrivener 2.05 mac

We’re compiling using default options for epub (in compile ebook options, nothing is ticked) and the file produced has a “blank” table of contents. I say “blank” because Calibre and iBooks and most other readers can “see” a table of contents just fine. However, the actual code does seem to have something odd about it as Sigil and the people at the iBookstore complain that the table of contents is empty.

We tested with the html file toc option, and the result is that Sigil and iBookstore then show a single file in the toc (Sigil TOC editor) – i.e. the html file we specified as the toc during compile. Other readers (Calibre, iBooks) still seem to be fine. The html file itself shows the appropriate entries, but those entries do not show up in the Sigil TOC editor or iBookstore, only the single html file itself.

We have read the Scrivener manual again and again and hope we aren’t doing something silly – we do understand it is the page break before setting that sets the table of contents up – and it does work, it produces a toc which most readers can read (as well as the html file having those specific files listed correctly)

The issue seems to be something to do with epub compatibility as Sigil’s TOC editor and iBookstore don’t respond in the way the other readers do…

We have no problem working around the issue manually in Sigil using their auto TOC function (based on headers i.e. h1, h2 etc) but hoping there’s a better way :stuck_out_tongue:

Has anyone run across this issue? Hope you have a solution you can share with us!

warmest wishes, maki

I fiddled around with the toc feature in epub export and found that toc entries are only produced by folders, if there is one additional file in the folder. If you only have files they do not show up in the toc.

Actually that’s not true - it’s entirely dependant upon how you set up your formatting options in Compile. To have items turn up in the ToC they just need titles and to start a new section (i.e. on a new page), as the op notes.

I doubt this is a bug because Scrivener follows the .epub specs very closely and there’s nothing special about the HTML table of contents, but it may be down to compile settings. It’s probably easiest if you send me the zipped-up project file (to kb-tech-support AT literatureandlatte DOT com) so that I can test for myself. Also please let me know how I can see the problem - do I just need to download Sigil and open the resulting .epub there?

Thanks and all the best,

:blush: I stand corrected. That’s because I don’t RTFM, but fiddle around. My apologies for bringing this up.

No need for apologies! I think we really need to put together a better overview of compiling an e-book seeing as it’s coming up a lot and the options required will be different depending on the project, simply because Scrivener allows uses to use any structure they want.
All the best,

Thanks very much Keith and juh!

Scrivener zipped project file on its way to you now, Keith.

Yes, if you download Sigil and open up the compiled epub using it, then F7 or the Tools|TOC editor will get you to what Sigil thinks the current TOC is.

We’ve also tried with other epubs, the ones we hand-built and the ones we made using Sigil itself seem to create a TOC that Sigil recognises. It hasn’t really been an issue before because most of the readers seem to see a TOC fine from the Scrivener 2.05 compiled epub, it’s just Apple are quite strict on what they will accept (and unfortunately don’t yet make very detailed tech documentation available to us to show us what exactly we have to meet, so it’s been a few weeks chasing this down. Until we opened the file in Sigil and found no TOC that Sigil could see, and then had the corroborating evidence with the subsequent single file for the compile with html (which was also the same their end for that second submission), we didn’t really see what they were talking about as all the other readers we tried did give a TOC)

Hope you can find the issue Keith, if it’s not specific to our files hopefully it’ll help out other iBookstore publishers too. Thanks again for your help!

warmest wishes, maki

Hi Maki,

I’ve just sent you a reply, but the table of contents appeared fine in Sigil for me. Are you using the latest version of Sigil?

Thanks and all the best,

Thanks Keith!

We were using Sigil stable 0.3.4 and previously 0.3.2 but having seen your screenshot realised there must be a newer version!

Downloaded Sigil RC 0.4 and I confirm your result. Thanks for going to all the trouble for us! Sorry, it was my fault for not checking for another Sigil version. Unfortunately RC 0.4 wasn’t available until 6 days ago (and we’d been struggling for the last month!)

I wonder if they’re using 0.3.4 or something similar on the Apple end of things? I’ll drop them an email to ask, and post back to the forum.

PS (below is copy of email on the way to you, am not sure how to get images on the forum yet!) using the same file we zipped just now to send to you,

here’s our screenshot from Sigil 0.3.4 with Scrivener 2.05 all compile TOC options unticked:

and one from Sigil 0.3.4 with Scrivener 2.05 Generate HTML TOC option ticked:

the Sigil changelog has some interesting points


maybe Sigil 0.4 is building a TOC now on opening? :

Sigil v0.4.0 ß3 2011.03.24
opening an HTML file now automatically builds a TOC from the headings

Thanks again for your help, and sorry again for our mistake!

warmest wishes, maki

Hi Maki,

Just replied via e-mail, but as I say there, I wonder what makes you think Apple are using Sigil at all? I would doubt it, unless you know otherwise. An .epub generated from Scrivener passes the standard epubcheck and so should be fine for the iBookStore, so could it just be that opening and saving in the old version of Sigil caused the problems? Scrivener generates a table of contents according to ePub specs, using an NCX file (which you can see if you open the epub in Adobe Digital Editions) - it sounds as though Sigil isn’t reading that at all.

All the best,

Hi Keith,

thanks again! I totally agree, it’s unlikely they’re using Sigil 0.3.4 but it may have been a coincidence that they were reporting the same things that Sigil was seeing – and now I realise as you point out that it may have just been opening the file in Sigil that was doing this…

Unfortunately the reason we were opening the epub in Sigil was because although the compiled epub passed epubcheck, iTunes Producer (used to deliver the file to iBookstore) complains there is an unmanifested file within the epub (we set the compile cover to “include iTunes cover art file for iBooks”)
and once the file is deleted using Sigil, iTunes Producer lets us upload.

Thanks to your kind help it looks like the next thing to try is unticking the iTunes cover art, to see how that turns out! (thereby bypassing Sigil, which is what I should have done in the first place…)

(email follows with the screenshots about the unmanifested file)

Dear Keith,

just a quick note to say thanks again, and follow up on this:

The book was finally accepted into the ibookstore!

Unticking the iTunes cover art did the trick (as did not have to manually remove the redundant file).

Thanks so much for your help, let me know any time you need a itunes producer tester! (I can’t guarantee we’ll have a book to upload just then but we’ll try our best!)

warmest wishes, maki

Hi Maki,

Congratulations on getting the book accepted into the iBookStore! That “iTunes Cover” art checkbox is now un-ticked by default seeing as it seems it’s only needed for moving e-books into iBooks manually, and not for other e-readers or if you are submitting an e-book to iBooks properly for sale - thanks for bringing all of this to my attention. And I’ll certainly take you up on the offer on testing out on iTunes Producer the next time you have a book to upload! :slight_smile:

Thanks and all the best,