Kindle bug breaks NCX TOC

[UPDATE: January 2016: Amazon now allow for publishers to embed their book covers inside the file before upload to KDP; if you are using a jpeg title page, I would advise that you embed your cover. This way Amazon’s system will not mistake your title page for the cover. Note also that embedding your cover requires specific code. See the KDP guide for more information.]

A client recently uploaded to Kindle Direct Publishing a new book that I designed for him that had a jpeg image for its title page—a trend that gives the title page a much more polished appearance and allows for the use of custom fonts—and we discovered an unfortunate bug: Amazon’s convertor breaks the NCX TOC, relinking the title page to the cover entry.

The file included both an HTML TOC and an NCX TOC; both contained the entry “Title” that linked to the title page jpeg. Nowhere in the code, including nowhere in the content.opf, was there any code indicating the inclusion of a cover in the file. This is because I know that Amazon do not want the cover embedded in an ebook file, but want the cover uploaded separately.

When you upload your cover and book file, Amazon adds a cover entry to the top of your NCX file; if you don’t have an NCX file (if you uploaded a Word doc or HTML file, for example), then the convertor creates an NCX file and creates entries for only those items bookmarked—your beginning, your HTML TOC—and adds the cover entry.

Because Amazon do not want the cover embedded, their system has been programmed to look for anything that resembles a cover and to overwrite it with the cover you upload. The unfortunate result is that if you have a jpeg title page, Amazon’s system can’t tell the difference and treats is as a wrongly embedded cover. Thus, Amazon breaks the link between the “Title” entry and the jpeg in the NCX TOC and relinks “Title” to the cover added upon upload. Thus you end up with an NCX TOC with both “Cover” and “Title” linked to the cover. Thankfully, however, the title page jpeg remains inside the book and is otherwise untouched.

The HTML TOC code is unchanged, so the link from “Title” to the title page remains intact there. When the user clicks on the Go to Table of Contents in their Kindle device or app, it links to the HTML TOC so the problem will not appear. The problem only appears in Kindle apps that allow the user to click on the optional NCX TOC.

My client also discovered ours was not an isolated incident: he had bought Ian McEwan’s Atonement, which also has a jpeg title page, and the problem is present in that file, too:

I informed Amazon of the issue and recently heard back from them that they were able to replicate the problem and are looking into a fix. I have asked them to let me know if and when this happens so my client may upload a replacement file (that will not then be broken) and I can inform my readers. Will see what transpires.

Share this!

12 thoughts on “Kindle bug breaks NCX TOC”

  1. I cannot say whether embedding the cover now works; I only suspect it does. I have not had a client since who elected to have a JPEG title page, and I only do ebook conversions now for myself and a few select clients: the cost of buying all the necessary devices to test on became prohibitive because I never did it full-time; I am primarily a writer, editor, and consultant who simply began doing conversions when clients starting asking for them.

  2. I have always worked with the cover embedded. That said, I just went back and tested it without the cover, and it turns out that the solution I described does not work if the cover is not embedded. In my case, embedding the cover proved to be necessary but not sufficient, as I still had to add those anchor tags. Was embedding the cover sufficient for you to fix the issue? If so, were you already linking to anchor tags?

    Bottom line on my end: for my NCX to properly link to my JPEG title page, I had to both (i) have the cover embedded, and (ii) make sure the NCX “Title” link was linking not to the title page’s HTML file itself, but to an anchor tag at the top of that file’s HTML body.

  3. The problem described in the original post occurred specifically because the cover was NOT embedded in the file; it was uploaded separately to Amazon, which was the only option back then.

    From reading your post, can we assume you did upload such a file to KDP, without the cover embedded, and this worked?

  4. The problem you described in your original post (broken NCX with title page link erroneously linking to cover page) occurred even with the cover embedded in the file, so if you’ve experienced it without the cover and I’ve experienced it with the cover, then it seems the problem occurs irrespectively of whether or not the cover is embedded in the file. I’m not sure what would happen without the embedded cover, but what I did observe was that with the embedded cover, the bug seems to disappear (not just in KindleGen but also on KDP) if the NCX nodes link to anchor tags at the beginning of each HTML file rather than to the HTML file itself. Apparently EPUBs split into multiple HTML files are often designed without any anchor tags, unlike MOBI/KF8 files generated by KDP, so perhaps these anchors somehow help guide the KDP parsers. Just a guess.

  5. Hi,
    Because Amazon now allow one to embed the cover in the file, it makes sense to do that instead of trying to find a workaround. At least one would think so. This way the cover is recognized as the cover, and the title page JPEG will be left alone. At least in theory.

    For curiosity sake, while the workaround you came up with works in the NCX, have you tried uploading such a file to KDP, one that does not have a cover embedded, to see if Amazon still break the link thinking the title page JPEG is the cover? I would think Amazon’s system would still break the link if upload the cover image separately. You cannot test the system by using Kindlegen, because that is only a first step; Amazon make other changes to your file when you actually upload it.

  6. I may have found a manual fix. I am assuming you have access to your EPUB code, that your HTML is split into multiple files, and that the NCX link to your title page references an HTML file rather than an anchor tag. Here is what fixed it for me:

    Let’s say your title page is in an HTML file called “title.html” and your NCX’s “Title” node has been linking to that HTML page, e.g. “[filepath]/title.html”. Open that “title.html” file, and right after the <body> tag add an anchor tag such as <a id=”_Title” />. Then update your NCX to have the “Title” node link to that anchor tag, i.e.: “[filepath]/title.html#_Title”. Finally, generate your MOBI file the way you’ve always done it, and check the results.

    Note: For consistency’s sake and to be on the safe side, I performed the tweak for every HTML file and its corresponding NCX node, though I suspect doing it only for the title page would suffice.

    That bug caused much aggravation, so hopefully this fix works for other people too! Let me know.

  7. You’re welcome. And you would think that Amazon would have fixed this by now. However, you said that your title page is all text. If so, the link should not be broken; it should not be going to the cover.

  8. Thank you for your blog.

    I was going a bit mental thinking it was something I was putting in / not putting in / putting in the wrong location, etc.

    The Title Page link – even if it is all text – still goes to the Front Cover of the book – aaah.

    At least I know now it wasn’t anything I was doing – somewhat of a newbie into the world of creating ebooks for upload to Kindle at Amazon.

    Thank you again.

  9. Hi Michelle,
    Thanks for the response. A customer just alerted me to this error yesterday, and I found your post via a quick search on the topic. I’ll try contacting Amazon. Thanks.
    p.s. First time visitor. Your blog is very informative.

  10. Thank you. Please share what you get back from Amazon if they respond. I would be curious to hear what they have done, if anything, to fix this bug.

  11. Hi Angie,
    No, Amazon has never responded to say whether or not they have fixed this issue. Have you tried contacting KDP through their “help” section?

Leave a Reply

Your email address will not be published. Required fields are marked *