Scrivener/KindleGen compilation problem

I didn’t see anyone else post about this specific problem, so here it is:
When compiling my manuscript into .MOBI format, I attach a cover image in the appropriate field. After compilation, the image is affixed to the .MOBI file, but it somehow negates the TOC link in the menu. The TOC is still available, but not reachable from the menu. Clicking on it brings up the cover image instead. The TOC begins on the next page, but shouldn’t the link connect to the actual object it indicates?

I hope someone can help. I’m working against a Friday deadline, even if it is self-imposed.
Thanks

I’m not seeing anything like that in a quick test. To better understand what steps are going into this result:

  • What do you mean when referring to the TOC link “in the menu”? In which program are you using this menu? I do all of my Mobi testing using Kindle Previewer, and in that I can just hit Cmd-T to jump to the section designated as contents. Is that what you are referring to, this menu, or within the NCX tree view, which you can see when clicking on the little “to do list” looking icon on the far right of the toolbar. Both should be going to the same thing though, the former is just a shortcut for going into the NCX view and double-clicking the “Contents” entry. I just want to make sure we aren’t looking at a peculiarity of a particular Mobi reader (i.e. maybe it works fine in other Mobi readers).
  • You mentioned just using the appropriate Cover compile option pane to set up the image, are you doing anything custom for the ToC? Is that just appearing automatically when you compile, or do you have a custom ToC somewhere that is being added as a normal text document?
  • If you enable the source files setting in the KindleGen compile option pane and compile with that, you’ll find a bunch of files in a folder beside the .mobi file, all of which go into the making of a Mobi (this way you could do custom tweaks before final assembly, if you were so inclined, but it’s also useful as a trouble-shooting tool as it lets us peak into what actually goes into the making of a Mobi book file). Navigate to that folder and open the .opf file in a plain-text editor (TextEdit works). Toward the bottom of the file you should see a line like this:

Is there a line reading precisely that, or is it slightly different? The important thing is that type = toc bit at the front. The rest can (and may) be different. If that is the same, if you glance at the list of ‘.xhtml’ files in this folder, verify there is one named “contents.xhtml” and try loading that file in a web browser to make sure it actually has your contents in it.

  • One final thing: check to make sure you’re using Scrivener 2.5 in the about window. I vaguely recall an issue like this from ages ago that has since been fixed.

Thanks for the quick reply. Please bear with me through my discussion forum format ignorance. I’d like to reply point-by-point, but my formatting skills are almost nonexistent. :blush:

First, I AM using version 2.5.

Also, I indicated “ToC link” when I should have said “ToC Button.” I was using the Kindle app for testing purposes rather than the Kindle Previewer.

I’ve checked the .mobi file on the Kindle Previewer. Clicking the buttons for Cover and ToC have the desired results. However, double-clicking Table of Contents in the Kindle Previewer NCX menu reveals the cover, not the ToC.

When Compiling for .mobi with KindleGen, I select the cover already installed in the Front Matter section of the Binder.

If I do not include the cover in the compilation settings, it does not appear, of course.

However, if I do include it, it appears, but keeps the ToC button from working. The ToC is there, on the pages immediately after the cover, and the hyperlinks work,but you can only reach them by going to the cover first, then turning the page. The ToC button brings up the cover, not the ToC.

The ToC is the one automatically generated from chapter headings during compilation, and it works just fine, once you can find it.

However, when I open the “contents.xhtml” file in my browser, I get this message:

This page contains the following errors:

error on line 15 at column 25: Namespace prefix mbp on nu is not defined
Below is a rendering of the page up to the first error.

Table of Contents

After checking the log file, I found several warnings, about 50, that read as follows:

Warning(inputpreprocessor):W29004: Forcefully closed opened Tag: mbp:nu
in file: /private/var/folders/ll/tc979tfj6z7fcxl67qdkfqlr0000gn/T/EBOOK_TEMP/Brain Child Compiling W:Log/contents.xhtml line: 0000016

These are followed by this statement:

W28004: Absolute value specified for CSS property in content is not supported by Kindle readers.

There is, obviously, more to the issue. However, the only problem I’ve experienced is the ToC button malfunction. Everything else works great.

It’s quite all right. Plain old text can communicate just as well as fancy formatting. :slight_smile: And look, you’ve got purple text already, you’ll fit right in.

Thanks for doing some detective work on this. It sounds like you’ve confirmed the problem exists off of the Kindle app, since it happens in Kindle Previewer as well.

The error you got in your web browser is probably okay. There are e-book extensions that browsers are not programmed to understand. It’s a very similar format, but they are not directly compatible.

The CSS warning wouldn’t impact where the links go in the ToC. That’s all hard coded into the description of the book, in the .opf and .ncx files. CSS just impacts what it looks like in the reader. The font size and that sort of thing.

Would it be possible to either get a zipped copy of the KindleGen source folder sent to our support address, or even better yet a zipped copy of the project? If that’s okay just put this forum thread URL in the message so they know to flag me on it.

It sounds like you might have found a bug, but it would be easier for me to examine the problem with first-hand examples.

Sure thing. Thanks for the help.