HTML Table of Contents

[Notjohn]

Originally Posted by Hitch

If you really feel compelled to nuke the toc.html, put it at the back of the book, using a short TOC ("Start Reading") at the front. Best of all worlds.

Hitch

I have seen a few books from New York publishers with exactly that at the opening page, plus probably a warning that the Goths will tear me apart if I pirate the book, and always an invitation to sign up for the mailing list.

This would work well in the awful Daniel Silva TOCs where fifty numbered (or, if he's feeling especially daring, date-lined) chapters are listed, one after the other for two or even three "pages."

Personally, I like the html TOC for its sales potential on Amazon's Look Inside sample. I tailor my chapter titles with Look Inside in mind. But I too use the virtual (NCX) index on my Fire tablet and my iPhone.

[DaleDe]

Originally Posted by Toxaris

The DX is no ePUB reader, so why should it use the ncx? I know ePUB3 does not use the ncx anymore, and I feel it is a bad change...

I know some like the HTML TOC, I just don't. I do get annoyed by them, but not enough to remove it from the book first or not to read the book at all. Bad formatting will do that, but not the precense of a HTML TOC.

It is not DX that used NCX but the Amazon converter that will use it to create a Mobi TOC. ePub 3, I believe, is breaking its connection with DAISY by replacing the NCX with a more HTML like syntax. If you hand code your ePub, then ePub 3 is easier to create and it is still used outside the document like the older NCX was. To the eBook Reader they can look the same. There is no requirement in ePub 3 to have an inline TOC.

The presence of an HTML TOC is not the correct term for ePub 3 since both are using HTML syntax although the semantics tags are new to HTML5. Note that similar semantics can be used to create a page list as well.

Dale

[JSWolf]

Originally Posted by Turtle91

I also thought I read somewhere that it was a good thing to have at the front of your book so that when people previewed a sample they would have an idea of the overall structure. So not just an annoyance. My personal reading app has a great ncx toc feature so I don't use the html toc very much/at all, but it doesn't keep me awake at night if I read a book that had one.

That's a very bad idea. The problem is a lot of samples are just too short to be of use and the ToC is useless in a sample and just takes up space. So if there is no inline ToC, then there will be more of the actual book to be able to be sampled.

[JSWolf]

Originally Posted by Hitch

Boys, Boys, Boys....


Tox, my sweetie, indeed, as DaleDe will mention in a moment, I fear you are to be disappointed. I know I was, when I saw that the NCX was being superseded. I've always had a soft spot in my heart for the NCX; I have liked the simple elegance of it.

What programs ignore the NCX ToC?

The way I'd do an inline ToC is to put it at the back of the ePub if the ePub was being used to create Kindle eBooks. For when the eBook is being read as ePub, the inline ToC would be removed. The problem with a ToC at the front is it takes up too much room from a sample so you get less of the book to read. A lot of samples are too small and the more crud you can do away with before the actually text, the more people can read of your sample.

[JSWolf]

Originally Posted by DaleDe

It is not DX that used NCX but the Amazon converter that will use it to create a Mobi TOC.

I didn't think Kindlegen used the NCX ToC to create an inline ToC for Mobi & KF8. I thought you needed an inline ToC because Amazon doesn't want to use the NCX to generate a ToC from.

[DaleDe]

Originally Posted by JSWolf

I didn't think Kindlegen used the NCX ToC to create an inline ToC for Mobi & KF8. I thought you needed an inline ToC because Amazon doesn't want to use the NCX to generate a ToC from.

I guess it depends on which KindleGen you use.

Dale

[Hitch]

Originally Posted by Toxaris

The DX is no ePUB reader, so why should it use the ncx? I know ePUB3 does not use the ncx anymore, and I feel it is a bad change...

<snip>

Somewhere in this discussion, the Amazon formatting guidelines came up. Hence Turtle's reply about the "thousands of devices that don't display the NCX," and my subsequent response about the DX. I know we're in the ePUB sub-forum, but unless I'm daft, MOBI/AZW/KF8/KFX came into this somehow...

Originally Posted by Notjohn

I have seen a few books from New York publishers with exactly that at the opening page, plus probably a warning that the Goths will tear me apart if I pirate the book, and always an invitation to sign up for the mailing list.

<snip>
Personally, I like the html TOC for its sales potential on Amazon's Look Inside sample. I tailor my chapter titles with Look Inside in mind. But I too use the virtual (NCX) index on my Fire tablet and my iPhone.

We do this all the time--the short TOC in the front, particularly for endlessly long "Chap 1, Chap 2..." TOC's.

You assert this bit about the Fire using the NCX, all the time. I suppose, because I haven't seen a book that's created sans a toc.html, I don't notice this behavior.

Originally Posted by DaleDe

It is not DX that used NCX but the Amazon converter that will use it to create a Mobi TOC. ePub 3, I believe, is breaking its connection with DAISY by replacing the NCX with a more HTML like syntax. If you hand code your ePub, then ePub 3 is easier to create and it is still used outside the document like the older NCX was. To the eBook Reader they can look the same. There is no requirement in ePub 3 to have an inline TOC.

The presence of an HTML TOC is not the correct term for ePub 3 since both are using HTML syntax although the semantics tags are new to HTML5. Note that similar semantics can be used to create a page list as well.

Dale

Dale, which KG are you using? I must have missed that trick (building the toc.html from the NCX). Did you mean the toc nav elements for ePUB3?

Originally Posted by JSWolf

That's a very bad idea. The problem is a lot of samples are just too short to be of use and the ToC is useless in a sample and just takes up space. So if there is no inline ToC, then there will be more of the actual book to be able to be sampled.

Yes, but that's JUST YOUR OPINION, Wolfie, dear. Nor is a TOC useless in a sample for the potential buyer that wants to get an idea of length therefrom, or for those authors that have clever TOC titles.

Originally Posted by JSWolf

What programs ignore the NCX ToC?

LOTS of Amazon readers do.

The way I'd do an inline ToC is to put it at the back of the ePub if the ePub was being used to create Kindle eBooks. For when the eBook is being read as ePub, the inline ToC would be removed. The problem with a ToC at the front is it takes up too much room from a sample so you get less of the book to read. A lot of samples are too small and the more crud you can do away with before the actually text, the more people can read of your sample.

Didn't you just say this? You are, according to Amazon guidelines, not to put the TOC at the rear:

Originally Posted by Amazon Publishing Guidelines 2015-3

3.3.6 TOC Guideline #6: Place the TOC at the Front of the Book
Place the HTML TOC towards the beginning of the book and not at the end of the book. This ensures that a customer paging through the book from the beginning encounters the TOC naturally. Incorrect placement of the TOC affects the accuracy of the “Last Page Read” feature. Correct placement ensures that the TOC appears in sample downloads of the book.

[BOLD emphasis added]

Originally Posted by JSWolf

I didn't think Kindlegen used the NCX ToC to create an inline ToC for Mobi & KF8. I thought you needed an inline ToC because Amazon doesn't want to use the NCX to generate a ToC from.

Hmmm. Inquiring minds want to know this, too. Not that it doesn't "want" to; simply that, AFAIK, it doesn't. However, if Dale is right, I'll learn me sumpin' today. :-)

Originally Posted by DaleDe

I guess it depends on which KindleGen you use.

Dale

Dying for your input on this, pls? If we've remained too stuck in our ways, I'd certainly love to know.

Hitch

[JSWolf]

Which programs that display ePub ignore the NCX ToC? Anything Amazon doesn't count as they don't do ePub.

[Hitch]

Originally Posted by JSWolf

Which programs that display ePub ignore the NCX ToC? Anything Amazon doesn't count as they don't do ePub.

That's somewhat true, Wolfie; one can, of course, upload an ePUB directly to the KDP, and the generated resulting MOBI will function on KF8-enabled devices much like an ePUB. And, if you load an ePUB3 with the landmarks toc, it will function pretty much exactly like one.

Anyway: I was, myself, speaking about Amazon devices, in response to Turtle's response to this post by Little.Egret: https://www.mobileread.com/forums/sho...08&postcount=4



Hitch

[Notjohn]

3.3.6 TOC Guideline #6: Place the TOC at the Front of the Book
Place the HTML TOC towards the beginning of the book and not at the end of the book. This ensures that a customer paging through the book from the beginning encounters the TOC naturally. Incorrect placement of the TOC affects the accuracy of the “Last Page Read” feature. Correct placement ensures that the TOC appears in sample downloads of the book.

There is much that is comical in the Guidelines, but this one is especially rich, worrying about "a customer paging through the book from the beginning," when Amazon does its level best to PREVENT customers from doing that. The average reader never sees the cover when he opens the book, never sees the TOC or title page, and never sees the perhaps vital information in the prologue etc.

[Turtle91]

Originally Posted by Notjohn

There is much that is comical in the Guidelines, but this one is especially rich, worrying about "a customer paging through the book from the beginning," when Amazon does its level best to PREVENT customers from doing that. The average reader never sees the cover when he opens the book, never sees the TOC or title page, and never sees the perhaps vital information in the prologue etc.

Ummmm... I regularly see the cover page in preview...if the book has one (I keep getting some books with just a plain graphic which is really annoying)...it may require me to scroll up if the book has a "start here" tag embedded...and, of course, if those particular pages are specifically hidden for a preview there's nothing I can do about that. I always assumed there was a step in the submission process where the author/publisher could select which pages to display?? I would be moderately shocked to learn that Amazon willy-nilly hid pages.

As the current replies to this thread seem to be a) replies to replies to replies, b) full of "I think it was mentioned", and c) quoted text exceeds new text, perhaps it's time to say no one here is going to sway any one else to their opinion and it's best to let the thread die?

[Hitch]

Originally Posted by shall1028

As the current replies to this thread seem to be a) replies to replies to replies, b) full of "I think it was mentioned", and c) quoted text exceeds new text, perhaps it's time to say no one here is going to sway any one else to their opinion and it's best to let the thread die?

While I thank you kindly for being so sensible as to the expenditure of my own time, if you don't mind, I'd like to be able to see DaleDe's response to my question about which KG is being used, and what cl settings, for a toc.html to be built from an NCX at Amazon. What he's said is new information to me, and I should like more data.

Originally Posted by Notjohn

There is much that is comical in the Guidelines, but this one is especially rich, worrying about "a customer paging through the book from the beginning," when Amazon does its level best to PREVENT customers from doing that. The average reader never sees the cover when he opens the book, never sees the TOC or title page, and never sees the perhaps vital information in the prologue etc.

I suspect that this was in response to Calibre mobis, about 5 years back. At that time, it was very common for the Calibre conversion to put a TOC.html at the REAR of the book. And you know quite well, nj, that the PG are rather hoary. ;-) And the front-matter SRL location, kiddo, has naught to do with how the progress calculation is calculated, whereas the TOC is used for that purpose. Surely you can concede that one is a matter of disgruntlement for a single person, the author/publisher, and the other quite possibly a cause for disgruntlement and dissatisfaction for many (the readers). If you step back and look at it, the "rule" makes perfect sense--ironic or not.

Originally Posted by Turtle91

Ummmm... I regularly see the cover page in preview...if the book has one (I keep getting some books with just a plain graphic which is really annoying)...it may require me to scroll up if the book has a "start here" tag embedded...and, of course, if those particular pages are specifically hidden for a preview there's nothing I can do about that. I always assumed there was a step in the submission process where the author/publisher could select which pages to display?? I would be moderately shocked to learn that Amazon willy-nilly hid pages.

Sorry-what's "just a plain graphic?" Not following you there.

Vis-a-vis publisher selecting which pages to display: ixnay. Nyet. No. Not so. Not at Amazon, B&N nor even iBooks. It's decided for them. At Amazon, it's the first ~10%. 5% at B&N, I believe, and I don't know at iBooks.

With regard to "willy-nilly hid pages," if you mean in the LITB, no, they don't. If you mean that the SRL (Start Reading Location) is deliberately set after the front-matter, yes, they do.

Hitch

[eschwartz]

Originally Posted by Hitch

Sorry-what's "just a plain graphic?" Not following you there.

I have seen it before.

The book has no semantic cover image (or possibly, just a picture of a penguin).
The cover may or may not be added as an additional HTML page.


It *can* be quite annoying, depending.

[Hitch]

Originally Posted by eschwartz

I have seen it before.

The book has no semantic cover image (or possibly, just a picture of a penguin).
The cover may or may not be added as an additional HTML page.


It *can* be quite annoying, depending.

Ah. The Dresden books are like this, isn't that right? No covers?

Hitch