Toc.ncx

[JDawg]

Hi folks,
Is there any way that I could control where the toc.ncx (the table of contents) file appears in my .mobi book? Right now, you can access the table of contents by
1) Go to>table of contents
2) Going to the back of the book manually, because the toc seems to be located after the last chapter.
I would like the table of contents be accessed these ways:
1) Go to>table of contents
2) Going to the table of contents manually, but in stead of the back of the book it would be located before the preface.
Sorry for the complicated post on a minor issue, but I would prefer to have my ToC at the beginning. Thanks for any help.

[DiapDealer]

This will probably be best answered in the Mobi or Calibre forum, but the short answer is; the TOC is probably at the end of the book because that's the default behavior when you convert an epub to mobi with calibre.

You're really talking about two different things. The "Go to>Table of contents" just jumps to the html version of the TOC... wherever it is in the book. So if you want it in the front, add an html TOC to your original source (before the preface) and tell calibre (if that's what you're using to convert to mobi) to NOT automatically add the table of contents.

With mobi, the toc.ncx file is only used to create/facilitate the chapter "jump points" on the progress bar. They allow you to jump to the various chapters with the joystick/d-pad.

[Alissa]

Originally Posted by JDawg

Is there any way that I could control where the toc.ncx (the table of contents) file appears in my .mobi book?
1) Go to>table of contents
2) Going to the back of the book manually, because the toc seems to be located after the last chapter.
I would like the table of contents be accessed these ways:

On a Kindle device, toc.ncx is never shown. The table of contents of a book which is shown when you operate Go to > table of contents is a part of the book content (html file) that is marked as a toc. It appears wherever you put it; at the end, before preface, or even in a middle (nobody wants such a placement, though.)

[JSWolf]

But nobody wants the ToC inside an ePub. ePub has a perfectly good external ToC. Blame the conversion software for putting the ToC (from toc.ncx) at the back. That is a software conversion issue, not an issue with toc.ncx.

Why not log it as a bug in Calibre or make it a feature request to be able to specify where the ToC goes when converted from toc.ncx?

[DiapDealer]

Originally Posted by JSWolf

But nobody wants the ToC inside an ePub. ePub has a perfectly good external ToC. Blame the conversion software for putting the ToC (from toc.ncx) at the back. That is a software conversion issue, not an issue with toc.ncx.

Why not log it as a bug in Calibre or make it a feature request to be able to specify where the ToC goes when converted from toc.ncx?

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?

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.

[JSWolf]

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.

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.

[DiapDealer]

some of them actually link the chapter headers back to the internal ToC. That is just wrong.

Correction: You just don't like it. It's too subjective for a right/wrong label.

[JSWolf]

Originally Posted by DiapDealer

Correction: You just don't like it. It's too subjective for a right/wrong label.

But doing it that way is not how it should be done. I know it's subjective. But ePub was designed with toc.ncx in mind as THE ToC. If publisher are going to do nonsence like internal ToC and chapter headers linked to the internal ToC, we may as well give up ePub and go back to text files. Hell, we may as well go back to writing on cave walls if the publishers are going to act like cavemen.

But seriously, it's a step backward to have an internal ToC for ePub. It's two steps backwards to then link the chapter headers to the internal ToC. The idea is to do away with Mobipocket since it's three steps back from ePub. Microsoft realized that ePub was better then MS Reader and that's why MS Reader is now dead. If it wasn't for the agency model, eReader would be dead too. But because of the agency model, it's what Fictionwise offers with DRM. Amazon is the only hold-out for Mobipocket. Yes, I know they own Mobipocket. But it's time to realize it's an obsolete format and lay it to rest.

The next step is to then do away with DRM so all ePub is the same (Apple doesn't count as it's not really true ePub).

[Lazer]

I wrote a forensic manual that simply HAD to have an "active" TOC for the book to be of any use and am quite happy with the way the ebook functions.

If you really wanted to write a book with a simple TOC that doesn't work as links to actual chapters you could certainly include it in the start of your book but I'd assume you'd also want the TOC.NCX too (as a linking TOC.)

With my book I wanted it to open at the Preface and certainly not at the TOC or metadata for that matter. I'll call it author (or self publisher's) preference. Having the TOC at the end of the book is also a bit of a "summary" for the reader to page through.

Tony Latham

[DiapDealer]

Originally Posted by JSWolf

But ePub was designed with toc.ncx in mind as THE ToC.

Jon, we're talking about creating mobipocket books here. For this particular discussion, just think of the ePub as "source-code" for generating mobi files (either with calibre or Kindlegen).

Are you seriously suggesting that people need to ensure their mobi source code complies to your personal ePub standards? That's just ridiculous. Not to mention presumptuous.

[osnova]

Originally Posted by JSWolf

a linked ToC internally which is not wanted and not needed.

Just my two cents: I would want both. The internal TOC is a tradition that makes book a book (as well as the title page, chapter division, preface, introduction, etc.). Without it, epub is just some text with navigation. I'll use the external one for convenience but the internal TOC is a must.

I am not a Luddite (see the list of my devices) and always on the lookout how the books can be improved. Even with the change from paper to electronic screen, a book should remain a book (not a twit, email, blog, etc.). It has a long history. It can gain new characteristics (video illustrations, etc.), yet it should be still recognizable.

=====

On another note. With all the talk of the superiority of epub, it does not have the dictionary or internal index support. I am not talking about one default dictionary, I am talking about a format that I can use. Come on, Mobipocket had it years ago. You can do fancy stuff with it (you can insert paradigm wordforms for a headword!)

I also have not seen a good, fast text search implementation (comparable to what Kindle offers). The Nook C only searches forward. The last may be not the format's fault but still.

You can put a gigabyte of structured text into a mobipocket on the Kindle (has been done with Wikipedia and such) and the search, indexing, navigation, etc. works great. Large epubs are slow (even if you do all the tricks). So, for a medium-sized novel, epub is great but for a large reference work it is nowhere near Mobipocket on the Kindle. I would love to see epub develop beyond eye-candy.

[JSWolf]

Originally Posted by DiapDealer

Jon, we're talking about creating mobipocket books here. For this particular discussion, just think of the ePub as "source-code" for generating mobi files (either with calibre or Kindlegen).

Are you seriously suggesting that people need to ensure their mobi source code complies to your personal ePub standards? That's just ridiculous. Not to mention presumptuous.

I'm not asking for my standards. I'm asking for ePub standards. ePub we designed with an external ToC for the express purpose of having an internal ToC.