Inline TOC from toc.ncx

[DMSmillie]

Originally Posted by JSWolf

Try converting an ePub with just an external ToC and see what you think.

Not sure if that's directed at me or the OP?

I know Calibre will create an inline TOC when converting to MOBI format, as long as you can set the correct regex to accurately identify the headings you want included in the TOC. It works most easily with books that are accurately coded (using h1, h2, h3, etc, for titles and headings) and/or that have chapter/section titles that include words such as "chapter", "section", etc. However it's tacked on at the end of the book, which is fine for personal use, but is less than optimal for commercial publication, particularly for non-fiction books, where you will likely want the inline TOC to appear as part of a free sample offered for download, to give the prospective purchaser an accurate and detailed overview of the book's content.

[DaleDe]

Kindle Gen should also pick up the external TOC.

Dale

[DMSmillie]

Neither Calibre nor Kindlegen create an inline TOC from the NCX TOC. They will incorporate the NCX data into the MOBI file so that it's there for the ereader device or app to make use of, e.g. on the Kindle, navigation point markers are placed on the progress bar, corresponding with the navigation points coded into the NCX file, and the 5-way control button can be used to skip to the previous or next navigation point.

[wannabee]

Hi Donna, Johny come lately here. Reading up on Mobi and finding your posts has got me concerned.

Originally Posted by DMSmillie

And the fact that, unless something has changed, a Calibre-created MOBI file won't work on Kindle for PC if you upload it to Amazon and specify that DRM should be added to the ebook.

Well that's one more reason for the argument against DRM. So I think we'll be OK there with our books because we're not going to use DRM.

Originally Posted by DMSmillie

I know Calibre will create an inline TOC when converting to MOBI format, as long as you can set the correct regex to accurately identify the headings you want included in the TOC. It works most easily with books that are accurately coded (using h1, h2, h3, etc, for titles and headings) and/or that have chapter/section titles that include words such as "chapter", "section", etc. However it's tacked on at the end of the book, which is fine for personal use, but is less than optimal for commercial publication, particularly for non-fiction books, where you will likely want the inline TOC to appear as part of a free sample offered for download, to give the prospective purchaser an accurate and detailed overview of the book's content.

Am I naive thinking that my epubs converted to Mobi in Calibre with default settings may not be Retail-Ready?
I'm proofing on an iPad with the Kindle App and MobipocketReader for the PC and they look pretty cool if I dont say so myself but have I missed something out that I'm not aware of?

Forgot to mention - I didn't rename the paragraph styles from the original source files (InDesign) so they are called all sorts of things (subsubsubhead etc.) that previous designer thought up

[DMSmillie]

Originally Posted by wannabee

Hi Donna, Johny come lately here.

Heh...most of us could probably be called that.

Originally Posted by wannabee

Reading up on Mobi and finding your posts has got me concerned.

Nooooo.......!

Originally Posted by wannabee

Am I naive thinking that my epubs converted to Mobi in Calibre with default settings may not be Retail-Ready?
I'm proofing on an iPad with the Kindle App and MobipocketReader for the PC and they look pretty cool if I dont say so myself but have I missed something out that I'm not aware of?

My focus here is pretty well solely on the inline TOC, Mark, in the context of the OP wanting to generate one from the data s/he's already coded in the NCX, and others puzzling over why anyone might want to do that.

Whether Calibre's method of adding an inline TOC to the end of a file is acceptable in any particular ebook intended for commercial distribution is essentially an editorial decision, as is the suitability of the content captured in that TOC.

Some books (e.g. novels with simple "Chapter One", "Chapter Two", etc, headings) may not need an inline TOC at all, or having it at the end of the book (and accessible via the "Go To..." menu) might actually be preferable compared to having it near the start of the book, since it's only going to be useful under a few very specific circumstances.

For books with more descriptive chapter titles, and in particular non-fiction books, one might (and I do emphasise "might"!) prefer to have the inline TOC in the conventional place near the start of the book, for two reasons:

1. it's where people will tend to look for it (decreasingly important as people become more accustomed to using e-readers, and using the "Go To" menu to access the TOC);
2. it ensures that the TOC (which, in content-rich books, usually provides an excellent overview of what the book covers) will be included in an automatically generated free sample, since that will generally be the first x% of the book (Amazon uses the first 10% of the book) (also less important if there are options for customising the content of any free samples being offered).

Beyond obvious things like ensuring accurate spelling, grammar and punctuation, I really don't think there are (yet) any absolutes in terms of e-book structure or formatting (though I know some disagree with that). It should simply be a matter of giving some thought to what will or won't work best with any particular book or series of books, and then adjusting that if necessary in the light of any feedback received from customers or information published elsewhere.

Originally Posted by wannabee

Forgot to mention - I didn't rename the paragraph styles from the original source files (InDesign) so they are called all sorts of things (subsubsubhead etc.) that previous designer thought up

That shouldn't be an issue in itself, Mark. If one is capable of creating a regular expression that will trap all of the headings and subheadings wanted in the inline TOC (and you clearly are! ), then not a problem. (Though I'd add here that ideally, you should aim to move towards accurate semantic coding of content (so headings are coded as headings, paragraphs as paragraphs, etc), since that's essential for anything more than absolute basic text-to-speech functionality, and also for possible e-reader functionality such as previous/next heading, paragraph, list, table, etc).

[wannabee]

Thanks for the thoughtful reply Donna. Very appreciative.

[tomsem]

Originally Posted by wannabee

Am I naive thinking that my epubs converted to Mobi in Calibre with default settings may not be Retail-Ready?
I'm proofing on an iPad with the Kindle App and MobipocketReader for the PC and they look pretty cool if I dont say so myself but have I missed something out that I'm not aware of?

Forgot to mention - I didn't rename the paragraph styles from the original source files (InDesign) so they are called all sorts of things (subsubsubhead etc.) that previous designer thought up

Your kilometerage may vary, but I would plan on doing some cleanup on any automatic conversion or export from InDesign (have you tried the free Amazon plugin for ID?). That means editing HTML.

For example, I like ebooks whose chapter headings link back to the 'inline' TOC. It really improves navigation, particularly on Kindle. But calibre will create not create such anchors.

Calibre is a great tool, but I would not consider it part of a quality eBook production workflow. A great list of ebook production resources can be found here:
eBook Architects

[wannabee]

Originally Posted by tomsem

Your kilometerage may vary, but I would plan on doing some cleanup on any automatic conversion or export from InDesign (have you tried the free Amazon plugin for ID?). That means editing HTML.

A great list of ebook production resources can be found here:
eBook Architects

Thanks tomsem, I agree - and always tidy up the files InDesign generates. Thanks for pointing out that resource page. I have some of these untilities but didn't know about that collection. Looks like I'd better make some more time to investigate.
I haven't tried the Amazon plug in. Looks like something extra to look into as well. Thanks mate.

[elmago79]

Thanks a lot to st_albert. That was exactly what I was looking for. I'm on a linux computer, so installing pearl won't be a problem. Right now I'm using a php script my brother was kind enough to make for me, but it is a bit of a hassle.

The reason I'm not using Calibre is what everyone is talking about. It just doesn't cut it for production for the reasons everyone is explaining. My clients have also have all sorts of weird requirements for the inline TOC, and all I needed was a way to automate the process a little (a poetry book I just made had more than 80 entries.)

As for converting EPUB to MOBI, I'm having good results I format the EPUB appropriately from the start and then make the appropriate modifications before generating the MOBI file.

JSWolf: I'm amazed by the amount of people that never use the "external toc" because the have no idea it is there, even in EPUB. So I keep the inline toc in the epub also, at least for the time being.

[JSWolf]

Originally Posted by elmago79

JSWolf: I'm amazed by the amount of people that never use the "external toc" because the have no idea it is there, even in EPUB. So I keep the inline toc in the epub also, at least for the time being.

But the reason they may not know of the external ToC is because of the internal ToC. So if ePub did not have an internal ToC, then people would ask about it and find out about it (IMHO).

I'm of a mind to remove internal ToC if there are not too many links from the chapter header.

[DaleDe]

Originally Posted by JSWolf

But the reason they may not know of the external ToC is because of the internal ToC. So if ePub did not have an internal ToC, then people would ask about it and find out about it (IMHO).

I'm of a mind to remove internal ToC if there are not too many links from the chapter header.

Some of the reading devices do not support external TOC hierarchy, or totally ignore any but the top link. For these an internal TOC may be quite valuable.

Dale

[JSWolf]

Originally Posted by DaleDe

Some of the reading devices do not support external TOC hierarchy, or totally ignore any but the top link. For these an internal TOC may be quite valuable.

Dale

Which buggy devices do not work properly with a toc.ncx file? If there wasn't an internal ToC, maybe people would be demanding that this bug gets fixed.

[DaleDe]

Originally Posted by JSWolf

Which buggy devices do not work properly with a toc.ncx file? If there wasn't an internal ToC, maybe people would be demanding that this bug gets fixed.

As I recall it was an iPad

Dale

[JSWolf]

Originally Posted by DaleDe

As I recall it was an iPad

Dale

iBooks, txtr, Bluefire do for sure work with a toc.ncx file. Maybe it's Stanza and if it is, Stanza is way buggy so it doesn't count.

[DaleDe]

Originally Posted by JSWolf

iBooks, txtr, Bluefire do for sure work with a toc.ncx file. Maybe it's Stanza and if it is, Stanza is way buggy so it doesn't count.

I could have mis-remembered. Are you sure iBooks has multi-level external TOC support?

Dale