Cover in TOC?

[gdgibson]

I'm converting a book for Kindle via InDesign > EPUB > Kindlegen (Kindle Previewer). My client has correctly pointed out that many Kindle titles include an entry for the cover in their in-line tables of contents. So I've set out to include an entry for his cover.

What I've done is go in with a text-editor after InDesign exports the EPUB and create an entry in the TOC using a standard hyperlink to the cover file. This link works in ADE and the Firefox EPUB reader: you can click on the "Cover" entry, and the book will open to the cover.

When I convert to Kindle, however, the link is dead. Clicking on the "Cover" entry brings no response in the Kindle Previewer, on the Kindle Mac Reader, or Kindle for iOS. On a Kindle Voyager, however, the link does work. Which would be great, except my client is proofing on an iPad.

When I exported from InDesign, I used the option to select an external image file for the cover. InDesign then generated an xhtml page for the cover, specified the cover image in the metadata, and listed the cover file in the spine with a linear="no" tag, according to the KDP guidelines.

As a work-around, I've created a duplicate page and stuck it at the end of the spine. The link I've set up to that page works, but once the TOC sends you there, you can't page forward to the rest of the front matter, and paging back puts you at the end of the book.

So is there any way to list the cover in the table of contents? And why would it be so hard to this?

[Hitch]

Originally Posted by gdgibson

I'm converting a book for Kindle via InDesign > EPUB > Kindlegen (Kindle Previewer). My client has correctly pointed out that many Kindle titles include an entry for the cover in their in-line tables of contents. So I've set out to include an entry for his cover.

For what it's worth--which has nothing to do with the rest of your question, obviously--I honestly don't remember the last time I saw any trade-pubbed book with a TOC entry for the cover. Not in an eBook and obviously, certainly not in print. I've just read 22 books in the last few weeks (had someone in the hospital, had a lot of time to read) and I've checked them all--nary a cover to be seen on a TOC. Ranging in fiction and non, both. Nonetheless...on to the question at hand:

What I've done is go in with a text-editor after InDesign exports the EPUB and create an entry in the TOC using a standard hyperlink to the cover file. This link works in ADE and the Firefox EPUB reader: you can click on the "Cover" entry, and the book will open to the cover.

When I convert to Kindle, however, the link is dead. Clicking on the "Cover" entry brings no response in the Kindle Previewer, on the Kindle Mac Reader, or Kindle for iOS. On a Kindle Voyager, however, the link does work. Which would be great, except my client is proofing on an iPad.

When I exported from InDesign, I used the option to select an external image file for the cover. InDesign then generated an xhtml page for the cover, specified the cover image in the metadata, and listed the cover file in the spine with a linear="no" tag, according to the KDP guidelines.

As a work-around, I've created a duplicate page and stuck it at the end of the spine. The link I've set up to that page works, but once the TOC sends you there, you can't page forward to the rest of the front matter, and paging back puts you at the end of the book.

So is there any way to list the cover in the table of contents? And why would it be so hard to this?

Well, mostly, because the cover isn't created, in Kindlegen, as a cover.html page. Or, if you do that, you can end up with the dreaded "double cover" after your client uploads at the KDP, when the cover that s/he uploads in Step 5 is embedded in the book file--no matter what you do.

When Kindlegen runs, it takes the first image it finds in the file, and assumes it's the cover. It creates it AS the cover image, and adds an element to the OPF for the cover, so you'll have the "go to" cover option. (Which is why, when discussing "whys," there isn't usually a TOC element for the cover, because of the Go To usage.) As no "page" actually exists for it, before you build the mobi, you can't link TO it. (As you're finding out when you try to force it).

An ePUB, however, does use the cover.html file, but Kindlegen doesn't. The link is dead in your test cases because the page that had the link, previously, is gone--it no longer really exists. I can't explain why it would work on the Voyage--it ought not.

In other words, Amazon doesn't WANT you to do this. They've already provided "go to" functionality for the cover, the TOC, the Start (at a minimum), and they feel that those folks who really want to go see the cover know how to click "go to" cover. (In fact, a startling number of the Ebooks I get from BPH's don't even slap the cover in there. It's done its job; you bought the book. Some have just a blank page with the title on it, IIRC. Someone at Amazon told me that their use statistics indicate that some huge percentage of the reading population don't even bother reading the front-matter, never mind paging back to the cover.)

You'd be better off leaving it alone, and explaining to the client that it really isn't normally "done," particularly not by traditional publishers. I'm fairly sure that out of nearly 3K books now, I can count the number of times we've even been asked for it on both hands. The client will find out, when s/he uploads at the KDP, that if you've put a cover.html file in, that s/he'll have the dreaded double-cover, both in the real book and in the LITB, which s/he won't want. And, as you've seen, if you put it in the rear (which Amazon gets pissy about, mind you, as they expressly say not to do that in the Guidelines), it doesn't work very well, either.

Honestly, in this case, client education is your best friend. The publishers that are putting "cover" in their TOC are, usually, Word-file uploaders who put a cover in the file, created an anchor link on the page, etc. When those files are Kindlegenned, the "page" still exists, and the link is still in the TOC that they built with Word. That's why you see some Indy-pubbed books with "Cover" in their TOC. (Many don't actually work, however--most don't, for variations of the reason given here.)

Hope that helps.

Hitch

[gdgibson]

Client education is your best friend.

That's actually a huge help, thanks. That's the tack I'll take.

Still, it bugs me. I've never done it and never had a client ask about it before, either. And of course the cover is always available in the ncx. But I have seen (and had the client show me) at least two TOC's with a "Cover" entry. And of course, there's the issue of my "cover" entry working on the Voyager (where the link works like a sort of javascript pop-up, and presents the cover image in an inset window with an "x" button in the top right corner to close it). I wonder if it's a feature that's somehow managed in-device?

Again, though, I'm comfortable with saying it's not a common practice.

[Notjohn]

Originally Posted by Hitch

Or, if you do that, you can end up with the dreaded "double cover" after your client uploads at the KDP, when the cover that s/he uploads in Step 5 is embedded in the book file--no matter what you do.

FWIW, the same thing happens in an epub if I label the included cover as "text" so the book will open there. It does indeed open there, at the included cover (or at least it did in my test run), but in front of that was the product image, making a second cover.

Originally Posted by Hitch

When Kindlegen runs, it takes the first image it finds in the file, and assumes it's the cover.

I loved to put a frontispiece in my non-fiction books. But of course it got suppressed in the conversion process! So I had to move the frontispiece to in front of Chapter One, so it wasn't a frontispiece at all!

And I read a thread this morning on the KDP forums where Serious authors were arguing that if one wishes to create "an enduring work of art," one wouldn't change anything because it's to appear in digital format. The changes in what I write, and how I write it, and especially how I present it, have been huge.

[Hitch]

Originally Posted by gdgibson

That's actually a huge help, thanks. That's the tack I'll take.

Still, it bugs me. I've never done it and never had a client ask about it before, either. And of course the cover is always available in the ncx. But I have seen (and had the client show me) at least two TOC's with a "Cover" entry. And of course, there's the issue of my "cover" entry working on the Voyager (where the link works like a sort of javascript pop-up, and presents the cover image in an inset window with an "x" button in the top right corner to close it). I wonder if it's a feature that's somehow managed in-device?

Again, though, I'm comfortable with saying it's not a common practice.

Hi:

Duh...(slap myself in the head), it's working in the Voyage because when you click the "Go to TOC" menu, it *also* pops up the Go To Cover item at the TOP of the TOC. However, the Cover isn't actually IN the Table of Contents. It's a function of how the Voyage works. I wasn't thinking last night, when I said that I didn't know "why" it was working. I reminded myself by slapping something on a Voyage, and remembered that "yeah, that's how that works."

Which two books? Which two books did your client show you that had "Cover" in their TOC? I mean, if you think about it, 99%, it has to be from the NCX, because who on EARTH would put "Cover" in a typed TOC? I don't think we've ever done it here, and as I said, we just pushed out something like our 3,011th book. So...??? Are those Indy-pubbed books, or is s/he assuming that (like on the Voyage) a function of the Go To options on Kindle is displaying something that's actually not in the TOC, but is on the Go To Menu?

I will say--from a not-ebook perspective, but from a layout/typography/publishing perspective, it would be incorrect to put the Cover in a Table of Contents for a print book. Yes, eBooks have different functionality, witness the Go To functions; but generally, it's just not done. I know that sounds stuffy and all that--but s/he ought to be advised that it isn't.

@NJ: how were you coding your frontispiece? Was it the first thing that kindlegen "saw" as part of the book, sans the cover?

Hitch

[Hitch]

FYI:

Because I saw that you posted on the KDP forums, as well, with this bit about how other publishers are "including the cover in the TOC," I went to Amazon and downloaded a few of the BPH books that showed the "Cover" as being in the toc.html, in the LITB.

And yup, you're right, it's listed there. However--the links don't work. For the very reasons that I listed, in this thread. If you click them, you're jumped elsewhere (in the book I mention below, to the second half of the copyright page.)

For example, download Between the World and Me, Ta-Nehisi Coates, from Random House. Link's there; doesn't work. Perhaps your client should try that, before s/he assumes that they all work?

Hitch

[Notjohn]

Originally Posted by Hitch

who on EARTH would put "Cover" in a typed TOC?

Well, I did, hoping to force the SLR to the cover. And it worked, after a fashion, though to be sure I got two covers, so I went back and stripped it out.

Originally Posted by Hitch

@NJ: how were you coding your frontispiece? Was it the first thing that kindlegen "saw" as part of the book, sans the cover?

I think I was uploading html at that time, and probably no included cover, so yes, most likely it was the first thing in the book.

Huh! If I HAD included a cover, d'you think the KDP would have suppressed that and left the frontispiece alone?

[Hitch]

Originally Posted by Notjohn

Well, I did, hoping to force the SLR to the cover. And it worked, after a fashion, though to be sure I got two covers, so I went back and stripped it out.

NJ: Amazon's usage details basically tell them that no matter what they, or authors or publishers want, most readers do NOT read any frontmatter. Trying to force your reader to the frontispiece or first "page" is just swimming upstream.

I think I was uploading html at that time, and probably no included cover, so yes, most likely it was the first thing in the book.

Huh! If I HAD included a cover, d'you think the KDP would have suppressed that and left the frontispiece alone?

I think if you did it the right way--created an ePUB with a cover in the images folder with the correct metadata, but no cover "page," per se, then, yes, that's exactly what I think would happen. But again: the SRL (Start Reading Location, rather than SLR) will show up most likely on the first full page of text after the TOC.

FWIW.

Hitch

[Notjohn]

FWIW, my book published yesterday opens at the title page. I hope I never have to revise it. In my experience, if I touch it, the next version will open in the middle of the TOC.

Pace Amazon, this reader HATES having to page back to see if there is an essential prologue that the stupid software has skipped. It is one of the reasons that I prefer print editions to e-books in non-fiction, which is what I mostly read. (I've even seen prologues that the author has warned MUST be read in order to understand the book.) Not every author, nor even every publisher, has learned to banish the acknowledgements page to the back of the book. As recently as 1990 I had a battle with a university press on that very subject. I wanted them to go with the Notes & Sources; the editor insisted that they go up front. I lost, of course.

[Hitch]

Originally Posted by Notjohn

FWIW, my book published yesterday opens at the title page. I hope I never have to revise it. In my experience, if I touch it, the next version will open in the middle of the TOC.

Pace Amazon, this reader HATES having to page back to see if there is an essential prologue that the stupid software has skipped. It is one of the reasons that I prefer print editions to e-books in non-fiction, which is what I mostly read. (I've even seen prologues that the author has warned MUST be read in order to understand the book.) Not every author, nor even every publisher, has learned to banish the acknowledgements page to the back of the book. As recently as 1990 I had a battle with a university press on that very subject. I wanted them to go with the Notes & Sources; the editor insisted that they go up front. I lost, of course.

I don't disagree with you-I was simply advising on the rationale on why the books open where they do. Nothing more.

Hitch

[Notjohn]

And I wasn't disagreeing with YOU, Hitch! Only with Amazon's rationale....