ePub to mobi via KindleGen has no pop-up menu

[AlexBell]

I've just done my first conversion from ePub to mobi/azw3 with KindleGen.

Although the conversion seemed to go well when I open the mobi file on my upgraded Kindle3 I can't do the usual menu>goto>table of contents - the table of contents option is greyed out, and all I see is the beginning, end, and location options.

Is this usual for KindleGen? Is there anything I can do to get the table of contents option to show?

I've attached the original ePub file and the mobi file

[Aerys]

You need to add the "TOC" entry in the GUIDE section of the OPF in order for the TOC option to be made available (see below).

<guide>

            <reference href="Text/Frontmatter.html#coverpage" type="cover"/>
            <reference href="Text/Frontmatter.html#coverpage" title="Start here" type="other.start"/>
        <reference href="Text/Frontmatter.html#TOC" title="Table of Contents" type="toc"/>
        
</guide>

Friendly reminder when you do the conversion from epub to mobi via Kindlegen , it uses the TOC you declared in the OPF not the entries in the NCX so it usually makes sense that your HTML TOC and NCX contain the same entries.

[AlexBell]

Originally Posted by Aerys

You need to add the "TOC" entry in the GUIDE section of the OPF in order for the TOC option to be made available (see below).

<guide>

            <reference href="Text/Frontmatter.html#coverpage" type="cover"/>
            <reference href="Text/Frontmatter.html#coverpage" title="Start here" type="other.start"/>
        <reference href="Text/Frontmatter.html#TOC" title="Table of Contents" type="toc"/>
        
</guide>

Friendly reminder when you do the conversion from epub to mobi via Kindlegen , it uses the TOC you declared in the OPF not the entries in the NCX so it usually makes sense that your HTML TOC and NCX contain the same entries.

Thanks so much, that's most helpful. Aren't ebooks fun? Putting the top line in the guide messed up the conversion with calibre, so it looks as though I'll need to put the lines you suggest in for conversion with Kindlegen and but comment them out for calibre.

I wish Amazon would just once in a while follow standards.

For what it is worth I think the HTML and toc.ncx ToCs have slightly different functions.

[AlexBell]

Thanks, again, Aerys - it worked like a charm except that as you say it uses the HTML ToC and not the one in the toc.ncx file. Is there any way of being able to show the one in the toc.ncx file?

[DaleDe]

Originally Posted by AlexBell

Thanks, again, Aerys - it worked like a charm except that as you say it uses the HTML ToC and not the one in the toc.ncx file. Is there any way of being able to show the one in the toc.ncx file?

AZW version 7 uses the HTML one and only that one except for the small lines in the progress bar which to toc.ncx

AZW 8 (KF8) uses the toc.ncx one.

You have no control over this so you should make them the same.

Dale

[DiapDealer]

I'm not certain if the Kindle Keyboard (with the latest firmware) is able to display the NCX ToC... even when it is a KF8. Otherwise... I agree.

[AlexBell]

Thanks to you both.

[Hitch]

Originally Posted by DaleDe

AZW version 7 uses the HTML one and only that one except for the small lines in the progress bar which to toc.ncx

AZW 8 (KF8) uses the toc.ncx one.

You have no control over this so you should make them the same.

Dale

Dale:

My Fire does not use the ncx in my uploaded K8 mobis, and believe me, I would know if it did, as I preview ~25 mobis/week. I will have to check, but I don't believe I've seen it used on our FireHD, 8.9", either. The only place I've seen an ncx used is in Kindle For PC/Mac, and I don't believe I have seen it used or even accessible in K4iPad. Have you had a different experience?

Hitch

[DiapDealer]

Hitch,

My Kindle Fire HD definitely uses the NCX file for its "Go to" menu on KF8 books; whether purchased or built by me. I know because: 1) all nested ToCs collapse and expand like they should. 2) my NCX ToCS are rarely identical to my html tocs. 3) I can go to the html toc from the ncx toc—you know... that thing that drives wolfie mad?!

I was told that the Paperwhite and the Touch all were capable of using the NCX file (if it's present) for KF8 books as well. I just wasn't sure if the Kindle Keyboard did.

Are you certain you're just not seeing an ncx toc that's identical to your html toc?

[Hitch]

Originally Posted by DiapDealer

Hitch,

My Kindle Fire HD definitely uses the NCX file for its "Go to" menu on KF8 books; whether purchased or built by me. I know because: 1) all nested ToCs collapse and expand like they should. 2) my NCX ToCS are rarely identical to my html tocs. 3) I can go to the html toc from the ncx toc—you know... that thing that drives wolfie mad?!

I was told that the Paperwhite and the Touch all were capable of using the NCX file (if it's present) for KF8 books as well. I just wasn't sure if the Kindle Keyboard did.

Are you certain you're just not seeing an ncx toc that's identical to your html toc?

Well!

LOL. It's entirely possible. I'm going to have to make one that's different to check.

(Hitch loads a recent book)

OK: On the Fire, (regular) no, I'm not seeing the ncx, when I use the "go to" feature. On the FireHD, I certainly do.

What's interesting to me is that when I view the NCX on the FireHD, the ncx is altered. On one of the books we made and finished up last week, there's a "Frontmatter" entry that we did not create, under which is nested the frontmatter (Title page, copyright page, map [for this particular book, obviously], and the HTML.toc [calm yourself, Wolfie]). The Introduction then moves back out in the hierarchy, followed by the Epigraph and Book One.

So: Kindlegen makes some decisions about the NCX, that are not the decisions that the bookmakers have made for the book. Holy S**T.

Diap, I'm glad you told me, but I'm less-than-ecstatic about this. I admit, we tend to load a book on the FireHD for checking only when said book has images, fleurons, or other graphical issues we need to check (because of the massive resolution differences, and thus the image problems); we use the regular Fire for regular book-checking. I never noticed the Go To worked differently. I'm debating now just how unhappy I am that Amazon's software is altering the ncx.

Thanks, gang.

Hitch

[DiapDealer]

I'm not certain what determines the nested Front Matter--perhaps guide entries?? I just know it doesn't happen on all books. Most of the time, with the generic ones I build, I see "Beginning", "Cover," and "End"... with my NCX (my fully intact NCX) falling between "Cover" and "End."

Off hand... I'd say all the standard epub guide entries from the OPF (minus the cover and start/text entries) are all collapsed under the Front Matter heading. Have to do some testing, I guess. "Beginning" is clearly the start/text guide item and "End" is the "Before You Go" Amazon addition.

Sorry for the slightly less than ecstatic revelation, Hitch.

EDIT: Well some quick testing rules out my OPF guide-item guess. Back to the drawing-board.

[Hitch]

Originally Posted by DiapDealer

I'm not certain what determines the nested Front Matter--perhaps guide entries?? I just know it doesn't happen on all books. Most of the time, with the generic ones I build, I see "Beginning", "Cover," and "End"... with my NCX (my fully intact NCX) falling between "Cover" and "End."

Off hand... I'd say all the standard epub guide entries from the OPF (minus the cover and start/text entries) are all collapsed under the Front Matter heading. Have to do some testing, I guess. "Beginning" is clearly the start/text guide item and "End" is the "Before You Go" Amazon addition.

Sorry for the slightly less than ecstatic revelation, Hitch.

EDIT: Well some quick testing rules out my OPF guide-item guess. Back to the drawing-board.

Yeah, that much, I could have told you. In the book I just checked (frontmatter listed in previous post), the named Guide items are the Start page (text), the copyright page and the Title page. Now...I suppose, in theory, that KDP could have extrapolated that everything between the first of those and the last was "frontmatter," but we've had some clients that demand this stuff display on the GoTo, but be at the back of the book. That would be interesting.

Amazon, Amazon...how I love thee, but how you make-a me crazy. (Anyone else here wrestling with the ubiquitous image-size issues brought on by the HD devices? UURRURUGHGHGHGHGH!).

(And don't get me started about Apple's image-display bug if an image in a div appears at the top of a landscape-turned page, wherein the text overwrites the image as if it doesn't "see" the div. Please don't give me links to Liz' post; she's clearly not dealing with that buggy issue, because we use her coding, or at least, we've TRIED to. Works fine until you rotate the damned book.)

Hitch

[dgatwood]

Originally Posted by Hitch

(And don't get me started about Apple's image-display bug if an image in a div appears at the top of a landscape-turned page, wherein the text overwrites the image as if it doesn't "see" the div. Please don't give me links to Liz' post; she's clearly not dealing with that buggy issue, because we use her coding, or at least, we've TRIED to. Works fine until you rotate the damned book.)

Is that still happening in iOS 6 for you? I got the impression that those issues were fixed a while back. Any chance you could post a sample EPUB (preferably a reduced copy with only a couple of pages) that demonstrates the problem?

[Hitch]

Originally Posted by dgatwood

Is that still happening in iOS 6 for you? I got the impression that those issues were fixed a while back. Any chance you could post a sample EPUB (preferably a reduced copy with only a couple of pages) that demonstrates the problem?

Yes, we're having that problem with any images that a) float left and b) appear at/near the top of a page in a div. It happens with divs; without divs; with padding, with margins, with every-possible-thing. Vertical alignment top, middle, bottom. It happens when the book rotates. If it's been fixed in iOS6, somebody forgot to tell the actual iPads.

No, I can't post a copy, even mostly redacted, client won't allow.

Hitch

[dgatwood]

If you haven't already, you might try adding:

html {
        -webkit-line-box-contain: block inline replaced !important;
}

I've seen this fix some subtle problems with the behavior of some floating elements near the tops of pages in some of my books. It probably won't help in your case, given that you're dealing with an image rather than a glyph, but if it does, let me know.