Quote:
Originally Posted by JSWolf
We should not have an internal ToC just to appease Amazon. They could design KindleGen to take toc.ncx and generate an internal ToC. No reason they cannot. And Calibre generates a linked ToC. Sure, it's at the back, but that's OK. An internal ToC (at the front) just makes us have to turn more pages to get past it.
|
@JSWolf:
I don't use Calibre to create mobi files, firstly; but more importantly, all Calibre does
is create an internal toc--an html.toc--which it links via the Guide; it does exactly what you are saying we should NOT have to do to 'appease Amazon.' Calibre isn't magically utilizing the ncx sans an html.toc; it uses the ncx navmap to create an html.toc and linking it to via the Guide items. The TOC "at the back" to which you refer (is also not due to Calibre; it's due to KindleGen/MobiGen) is the very TOC you're saying we don't need.
So, call it by any other name, but the "Calibre TOC" that you're saying is
sufficient is the selfsame "internal TOC" that you're saying we should not create to appease Amazon. More importantly, and more relevant to the discussion, if you're using Calibre you ARE "infesting the epub with an internal TOC;" you're simply allowing Calibre to do it for you. The "perfectly good external toc" you're referring to, a few posts ago, does not exist for Mobi/PRC; if you are discussing those created by Calibre, those have INTERNAL TOC's, created as I've described.
My point was, and still is: any user who simply has an epub with an ncx solely will NOT get a user-viewable and usable TOC via KindleGen or MobiGen sans an html.toc that is linked via the Guide. NOT the ncx.
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.)