Quote:
Originally Posted by JSWolf
I think you've got it somewhat wrong. ePub can have two different ToC. One internal and one external. The NCX file it the external ToC. if your ToC is in the NCX file, you don't need the internal ToC.
When you convert ePub to Mobi, the NCX gets converted to a linked ToC that is at the back of the Mobi. If you have both an NCX and an internal ToC, you may or may not end up with two ToC in the Mobi. But if the requirement is to have an internal ToC near the front of the Mobi, there there is no reason at all that Kindlegen could not manage that by using the NCX file. The fact that the NCX gets relegated to the back is not my concern. My concern it to get rid of any internal ToC. And the worst ones of all are when the publisher links the ToC headers back to the internal ToC. That's just wrong for an ePub.
What does Kindlegen do with the NCX? I knwo what Calibre does with it. It creates a linked ToC at the back of the Mobi.
|
@JSWolf:
I'm sorry...but you're simply incorrect. What you see, via Calibre, is nothing more than
an internal TOC created via
the use of the navmap in the ncx.
I'm really very well aware of what an ncx is versus a Guide-linked html.toc (what you are calling an "internal toc"). What Calibre does is create a Guide-linked internal, html.toc; it is doing EXACTLY what you say we should not do to kowtow to Amazon. That toc displayed by Calibre is absolutely not some dynamic, created-on-the-fly usage of the ncx; that is a plain old internal toc, created by Calibre, linked via the Guide, as per the Amazon specs.
Just because Calibre creates it doesn't make it something it isn't. That's an internal toc, just like Amazon wants. That is NOT an ncx (aka "external TOC"). It simply takes the navmap, makes an internal toc, which, via use of KindleGen, gets popped in the back of the book.
HTH,
Hitch
(Please check out
SHAKEN: STORIES FOR JAPAN--Great reads, great authors, great cause; 100% of all royalties go directly to tsunami, earthquake and radiation victims in Japan.)