Quote:
Originally Posted by DiapDealer
I just knew this question would draw you out of the woodwork. 
There are no bugs here, Jon. Only personal preferences (placement) and what you like/don't like (two ToCs)... and differing workflow practices. Why would you even care how mobi's are made?  |
I care how Mobipocket eBooks are made because with the issues in putting the ToC at the back using toc.ncx, it's causing the publishers to put in a linked ToC internally which is not wanted and not needed. Yes, this is a software issue. Amazon isn't fixing their software and Calibre isn;t being fixed. So when ePub > Mobi happens, if there is no internal ToC, the ToC ends up at the back of the Mobi and this is not how most people reading Mobi want it. This is not how amazon wants it. So those of us using ePub get stuck with a ToC that's not needed and not wanted when we have a perfectly good external ToC.
Quote:
My own workflow is to build an ePub with a Toc (html) inside the ePub—exactly where I want it; front, back, middle. Then I convert the ePub to mobi... I get a happy mobi with a ToC (where I want it) and the ncx jump-points everyone seems to like. Then I yank that html ToC out of the ePub and tweak the OPF file. Jon (and anyone else who doesn't like ePubs with internal AND external ToC's can do their "happy, happy... joy, joy" dance.
Problem solved... without inventing bugs that don't exist. 
|
That is a very nice solution to the problem. But most publishers don't do that and some of them actually link the chapter headers back to the internal ToC. That is just wrong. This is ePub, not Mobipocket. If the conversion software allowed specifying where the internal ToC (toc.ncx > internal ToC0 gets put, then we'd not have to put up with internal ToC from publishers that don't get it.