ebooks made with Sigil opening at different places when opened on Kindle

[Hitch]

Originally Posted by Notjohn

In my experience, that's where the dread double-cover problem arises, when I pointed to the included cover. (Very few examples to go by, to be sure. I think I did this only once, and that was a trial to see if I could force the downloaded book to open at the cover if I gave it the "semantic" of text. I ripped out both cover and semantic the same day and haven't gone back to that well since.)

NO. That is 100% wrong, NJ.

All you have to do is remove the cover.html. Leave the cover.jpg (or whatever) image in the Files folder. Point to it, and assign the COVER semantics. Build MOBI. Voila. Do that, and you will NEVER have a double-cover.

We haven't had one in, geeze, I don't know, four years now? Which would be somewhere in the 2,000 book figure? I'm pretty sure, if it were going to happen, in that scenario, it already would have.

@Doits:

Yes. You are correct. Dead on. If you forget, and leave the cover.html or XHTML file in, it's a crapshoot. Sometimes, it suppresses the "extra" and sometimes, it doesn't. The safest method is, remove the cover.html file, and follow the rest of the destructions. :-)

Hitch

[Notjohn]

Originally Posted by Hitch

NO. Leave the cover.jpg (or whatever) image in the Files folder. Point to it, and assign the COVER semantics.

I'm shaking my head in befuddlement, just as I did all day Wednesday.

Let me see now: I point to the image with what? The TOC? And I can right click on an image and assign a "semantic" to it? Good grief.

And this epub will be welcomed at Barnes & Noble, Apple, and Kobo?

[Doitsu]

Originally Posted by Notjohn

Let me see now: I point to the image with what? The TOC? And I can right click on an image and assign a "semantic" to it? Good grief.

No offense, but for someone who has published the "Guide to Kindle Publishing 2016" your technical skills leave somewhat to be desired.

KDP books must have an internal cover image that must be defined in epub2 books via a cover metadata entry and in epub3 books via a cover-image properties attribute. Since Sigil will automatically generate these entries all you have to do is remove the cover html file before you upload your book to KDP. (This step is necessary, because KindleGen might not automatically delete the cover.html file.)

FYI, assuming that you added a cover image with the id cover.png, Sigil will add the following entries if you create a cover page via Tools > Add Cover...:

a) EPUB2:

content.opf

<meta content="cover.png" name="cover" />

  <guide>
    <reference type="cover" title="Cover" href="Text/cover.xhtml"/>
  </guide>

b) EPUB3

content.opf

<meta content="cover.png" name="cover" />

 <item id="cover.png" href="Images/cover.png" media-type="image/png" properties="cover-image"/>

  <guide>
    <reference type="cover" title="Cover" href="Text/cover.xhtml"/>
  </guide>

nav.xhtml (landmarks nav)

      <li>
        <a epub:type="cover" href="../Text/cover.xhtml">Cover</a>
      </li>

Originally Posted by Notjohn

And this epub will be welcomed at Barnes & Noble, Apple, and Kobo?

That depends on the apps and epub versions that these booksellers use. All fully epub2/epub3-compliant apps should display the cover image, if you generated it with Sigil. The only difference between books for KDP and other publishers is that you won't have to delete the cover html page.

[DiapDealer]

Didn't the Kindle Publishing Guidelines used to recommend (for the purposes of maintaining compatibility with epub publishing standards) marking the cover-page (html) as "linear=no" as well as including the cover image meta/property? That way, the html cover page needn't be deleted and there was no duplication. Is that not a recommendation of Amazon's any more?

I admit it's been a hell of a long time since I downloaded/read their publishing guidelines.

[Doitsu]

Originally Posted by DiapDealer

Didn't the Kindle Publishing Guidelines used to recommend (for the purposes of maintaining compatibilty with epub publishing standards) marking the cover-page (html) as "linear=no" as well as including the cover image meta/property? That way, the html cover page needn't be deleted and there was no duplication. Is that not a recommendation of Amazon's any more?

I admit it's been a hell of a long time since I downloaded/read their publishing guidelines.

It's no longer in the Amazon Kindle Publishing Guidelines, but it definitely works for html cover pages that don't contain additional text. With a linear="no" spine entry for cover.xhtml, cover.xhtml will be suppressed and KindleGen will display the following message:

Info(prcgen):I1052: Kindle support cover images but does not support cover HTML. Hence using the cover image specified and suppressing cover HTML in content.     URL: \OEBPS\Text\cover.xhtml

So far so good, however, if the cover.xhtml file contains additional text, KindleGen will also display the above message but it'll keep the cover html page and move it to the end of the book. (If the additional text in cover.html is deleted, the cover page will no longer be displayed at the end of the book.)

For the above reasons, I recommend deleting cover.xhtml before running KindleGen or uploading epub books to KDP,

I attached a sample file that you can play with. It contains a cover.xhtml file (with additional text) and a linear="no" spine attribute.

1. If you compile it as is, cover.xhtml will be moved to the end of the book.
2. If you remove the text from cover.xhtml before running KindleGen, it'll be completely suppressed.
3. If you remove the text from cover.xhtml and the linear="no" attribute before running KindleGen, it'll be completely suppressed.

BTW, the Kindle Publishing Guidelines only mention the cover metadata entry for epub2 books and the properties="cover-image" entry for epub3 books and warn against using any other method:

4.2 Internal Content Cover Image Is Mandatory

Kindle books must have an internal cover image provided for use within the book content. Provide a large, high-resolution cover, because Amazon quality assurance will fail the book if the cover is too small.
Do not add cover images to the content in any way other than those described in this section or the cover might appear twice in the book.

IMHO, these instructions and the I1052 KindleGen message are a clear indicator that Amazon doesn't want authors to include a cover html page.

[Hitch]

Originally Posted by Notjohn

I'm shaking my head in befuddlement, just as I did all day Wednesday.

Let me see now: I point to the image with what? The TOC? And I can right click on an image and assign a "semantic" to it? Good grief.

And this epub will be welcomed at Barnes & Noble, Apple, and Kobo?

nj: how the hell do you NOT know this? We've had this damn discussion before. I know for a fact that we discussed it on the KDP forums. I told you this in an email exchange that you and I had, some time back. ???

and NO, this has nothing to do with ePUBs for distro. For that matter, this has sweet you-know-what to do with Sigil, but...

Originally Posted by Doitsu

No offense, but for someone who has published the "Guide to Kindle Publishing 2016" your technical skills leave somewhat to be desired.

Yes, I'm sorry, nj, but I am forced to concur with this sentiment. Are you just smoking whacky tabacky? What's up with this question/series of questions? I'm surprised, genuinely, at this.

KDP books must have an internal cover image that must be defined in epub2 books via a cover metadata entry and in epub3 books via a cover-image properties attribute. Since Sigil will automatically generate these entries all you have to do is remove the cover html file before you upload your book to KDP. (This step is necessary, because KindleGen might not automatically delete the cover.html file.)

Yes, that's what we do. For typical fiction books, simply yank the cover.html, make sure that the Cover semantic is assigned to the image, save, build mobi. Bob's yer uncle.

(Snippage)

That depends on the apps and epub versions that these booksellers use. All fully epub2/epub3-compliant apps should display the cover image, if you generated it with Sigil. The only difference between books for KDP and other publishers is that you won't have to delete the cover html page.

Sigil pretty much does all the heavy lifting. All you have to do is dupe the ePUB, and proceed.

OR, as Diap and Doits mentioned, use linear="no" if you want one ring to rule them all. As Doits clarified, the cover.html cannot have ANY text on it, for this to work. Personally, we make other tweaks, in our "ePUB4MOBI" files, because I am picky about how this or that displays, and what works perfectly in ePUB, for ePUB readers, may not work exactly as I wish in MOBI. But that's how we roll. No reason you can't make it as simple as we've just explained.

And whatever you're drinking, stop drinking it.

Hitch

[doubleshuffle]

Originally Posted by Hitch

Are you just smoking whacky tabacky?

Apologies, this is as OT as it gets, but "whacky tabacky" made me think of the sublime Judy Henske's "Hooka Tooka". It's a hoot, particularly the introduction, so I'll leave it here to lighten the mood a bit.

[John Laidler]

I have been reading this thread with interest because when I uploaded my little book as an ePub created in Sigil I deleted every reference to the cover, including the file itself. The interesting thing is my book opens correctly and has a cover image when viewed in an e-reader.
So I have just gone onto Amazon and downloaded my mobi file again and used Calibre to change it into an epub which I could open and view in Sigil.
This is where it gets interesting, because the opf file I uploaded had no references to the cover but the opf I have extracted from the downloaded mobi file does! Clearly, in the conversion process Amazon has put in the opf the entries which were missing. They have also added the missing cover.jpg in the list of images.
It all works but I think I should probably go back and upload the epub again with the correct entries and cover.jpg file.

I can post the extra lines which have been added by Amazon if anyone wants me to - and I can work out how to post code here.

Edit: (just worked out how to show code)

This in the metadata section of the opf:

   <meta content="cover" name="cover" />

This in the manifest:

 <item id="cover" href="Images/cover.jpeg" media-type="image/jpeg"/>

And this in the guide section:

<reference type="cover" title="Cover" href="Text/titlepage.xhtml"/>

To reiterate, I did not have these lines in the opf file I originally uploaded, having deleted them. Amazon's magic elves must have added them.

[DiapDealer]

Originally Posted by John Laidler

So I have just gone onto Amazon and downloaded my mobi file again and used Calibre to change it into an epub which I could open and view in Sigil.
This is where it gets interesting, because the opf file I uploaded had no references to the cover but the opf I have extracted from the downloaded mobi file does! Clearly, in the conversion process Amazon has put in the opf the entries which were missing. They have also added the missing cover.jpg in the list of images.

Don't assume that Amazon has added anything, there. The conversion to epub (whether converting with calibre or "unpacking" with KindleUnpack) can just as easily be responsible for those opf additions/changes. Both processes tend to try and create a "standard" epub from the binary contents of a kindlebook (including creating an html cover-page from an image that was clearly intended to be a "cover"). KindleUnpack has an option to dump the raw content of a Kindlebook if you really want to see what Amazon has done to your original epub!

[John Laidler]

Originally Posted by DiapDealer

Don't assume that Amazon has added anything, there. The conversion to epub (whether converting with calibre or "unpacking" with KindleUnpack) can just as easily be responsible for those opf additions/changes. Both processes tend to try and create a "standard" epub from the binary contents of a kindlebook (including creating an html cover-page from an image that was clearly intended to be a "cover"). KindleUnpack has an option to dump the raw content of a Kindlebook if you really want to see what Amazon has done to your original epub!

On reflection, it did occur to me that perhaps Calibre, which I had not used before, might have made these changes. However, the book I uploaded with the stripped down opf seems to behave itself.
I think I will still upload the book again with everything in place except with the cover.xhtml file removed.

[DiapDealer]

Originally Posted by John Laidler

I think I will still upload the book again with everything in place except with the cover.xhtml file removed.

I don't think you can go wrong with that approach.

[Hitch]

Originally Posted by DiapDealer

Don't assume that Amazon has added anything, there. The conversion to epub (whether converting with calibre or "unpacking" with KindleUnpack) can just as easily be responsible for those opf additions/changes. Both processes tend to try and create a "standard" epub from the binary contents of a kindlebook (including creating an html cover-page from an image that was clearly intended to be a "cover"). KindleUnpack has an option to dump the raw content of a Kindlebook if you really want to see what Amazon has done to your original epub!

I would never dare disagree with Diap, but, I will say that the intake processes and the PW (Publishing Workflow) at Amazon would, generally, add those things to the mobi, assuming that you did, of course, upload the cover at step 6. (It's 6 now, right? Not 5 anymore? Anyway...)

Otherwise, kids and kiddles, the mobis created from Word files would never work.

Right?

Hitch

[Notjohn]

What an amazing conversation. In the end, I am doing exactly what Doitsu and Hitch recommend, except that I leave the cover in place when I upload to the KDP. That works nearly every time, and when it fails, I fix it. I'd rather not maintain different epubs for the KDP and the others.

Though I am still puzzled at the notion that I apply a semantic to an image in the Images folder, as opposed to the xhtml file containing it. (And no, Hitch, you never, never told me any such thing.) But in fact I have never applied a "cover" semantic to the xhtml file, because it's already so labeled.

Of course my technical skills pale beside yours. That's precisely why I'm qualified to write a guidebook. It's not engineers who write tech manuals, not in successful companies.

[Hitch]

Originally Posted by Notjohn

What an amazing conversation. In the end, I am doing exactly what Doitsu and Hitch recommend, except that I leave the cover in place when I upload to the KDP. That works nearly every time, and when it fails, I fix it. I'd rather not maintain different epubs for the KDP and the others.

Though I am still puzzled at the notion that I apply a semantic to an image in the Images folder, as opposed to the xhtml file containing it. (And no, Hitch, you never, never told me any such thing.) But in fact I have never applied a "cover" semantic to the xhtml file, because it's already so labeled.

I could swear that we had this discussion over at the KDP forums, nj, but I've posted there thousands of times. I could very easily be mistaking a discussion with someone else, for a chat with you. If I didn't, my apologies. I certainly wasn't hiding it. At least, not intentionally. (There are things that we do, about which I see questions both here and there, that I don't answer. Admittedly. I suck that way. But this one, I know I've answered a bunch of times. Where, might be the question, however. Again: my apologies.)

Of course my technical skills pale beside yours. That's precisely why I'm qualified to write a guidebook. It's not engineers who write tech manuals, not in successful companies.

You confuse me with this, but I'll defer to you, as I certainly don't write manuals for anyone. Other than my long-suffering crew, which objects to MOST of what I give them. :-)

Hitch

[Notjohn]

When I was young, I supported my (novel-)writing habit by writing tech manuals for my classmates who had graduated as engineers. Even after I became self supporting, I used to pick up mad money as a consultant for the Justice Department, writing "executive summaries" for academic research papers on such arcania as Community Based Policing. You can't imagine how much money there is, or anyhow was, in "consulting" for the US government!

My point is that experts aren't very good at explaining themselves to the public. They need interpreters. (If you wrote a formatting manual, however, I would buy it and retire mine.)