Quote:
Originally Posted by wannabee
Hi Donna, Johny come lately here.
|
Heh...most of us could probably be called that.
Quote:
Originally Posted by wannabee
Reading up on Mobi and finding your posts has got me concerned.
|
Nooooo.......!
Quote:
Originally Posted by wannabee
Quote:
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? |
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:
- 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);
- 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.
Quote:
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).