View Single Post
Old 08-22-2018, 09:35 PM   #13
slowsmile
Witchman
slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.
 
Posts: 628
Karma: 788808
Join Date: May 2013
Location: Philippines
Device: Android S5
@st_albert...You've raised several issues and I have to say that I don't agree with you on most of your suggestions. This is going to take some explaining, so bear with me.

Quote:
Code:
[ERROR]: Bad cover position. The cover image file should always be the first file in Sigil's Book Browser file list.

which is misleading, because according to the KDP publishing guidelines, version 2018.2, section 4.2, pp 14-15, there should not be a cover.xhtml file at all:
Quote:
Do not add an HTML cover page to the content in addition to the cover image. This may result in the cover appearing twice in the book or cause the book to fail conversion.
First your suggestion that you should never put a cover image into epub for KDP uploads. Well what you say might be true for epub vendors like iBooks, Nook etc but it is not true for epub uploads to KDP. You must also never upload a Word doc with cover image to KDP otherwise you will get a double cover in the ebook. But whenever you upload an epub to KDP -- during the conversion process -- it's well known that KDP will always either add or replace any epub cover image with the Amazon Kindle product image which is loaded separately. So, for KDP uploads only, there is absolutely no need to remove the epub cover image because it will always be replaced by the product image on conversion to mobi. Also if you are testing your epub before upload it also makes sense to test it with the cover image in place.

Now to all the reasons why I still consider using the opf guide cover reference as the best way to get the cover file name.

Your suggestion about using the metadata cover reference would fail because it does not take into account all instances of epubs being produced from different doc-to-epub converters. To illustrate this, here is the metadata cover ref I get in the opf metadata when I load an epub created by Scrivener into Sigil:

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

How can I get the cover file name from that line? What I really want is the href, which is not there. Also, you cannot rely on 'name="cover"' being the name of the cover file. You really need the href to be sure.

You also cannot use the landmark nav ref in the toc.ncx due to the fact that not every indie author puts a cover reference in the Logical TOC for their KDP ebooks. I've seen plenty of ebooks with a Logical TOC that does not have a cover entry. So this method is also not a reliable way to get the cover file name.

The only two searchable references that you should be able to use to get the cover file name are the cover "id" in the manifest or the cover "type" in the opf guide because they both contain hrefs.

Manifest cover ref:
<item id="cover" href="Text/cover.xhtml" media-type="application/xhtml+xml"/>

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

My own preference is to use the opf guide ref because 'type="cover"' is usually the same across all doc-to-epub converters whereas I'm not so sure about how the manifest cover id name might vary across different doc-to-epub converter outputs.

Last edited by slowsmile; 08-22-2018 at 11:58 PM.
slowsmile is offline   Reply With Quote