[KDPValidator] Validate epubs for KDP upload only

[jhowell]

Originally Posted by slowsmile

How can a cover IMAGE be present when the cover PAGE is not there??

The answer is in the Kindle Publishing Guidelines. The file containing the cover image is marked in the OPF. It is not referenced from any HTML files.

[DiapDealer]

Originally Posted by slowsmile

But isn't the cover IMAGE situated in the cover PAGE ??

It does not HAVE to be, no. The cover IMAGE for a KDP-bound epub will most times not be referenced by ANY (x)html page in the epub.

Originally Posted by slowsmile

So how can you not have a cover PAGE while at the same time have a cover IMAGE in an epub??

Easily. By removing the cover PAGE and leaving the cover IMAGE. Why is this so hard? Epubs use a cover PAGE; KindleBooks use a cover IMAGE.

Originally Posted by slowsmile

Unless I'm missing something, you seem to be inferring that the cover IMAGE is not situated in the cover PAGE but is entirely separate from the cover PAGE. I admit that I am having a problem with that.

I am not inferring anything of the sort. I'm flat-out declaring it. Because it's true.

Originally Posted by slowsmile

How can a cover IMAGE be present when the cover PAGE is not there??

Because as I've pointed out many times already, they two are different things. A cover PAGE is an xhtml page. A cover image is a graphic image file (which may or not be included in an xhtml page).

Originally Posted by jhowell

The answer is in the Kindle Publishing Guidelines. The file containing the cover image is marked in the OPF. It is not referenced from any HTML files.

Exactly. The cover IMAGE is denoted in the opf file by a meta entry, as Doitsu and others have tried to clarify already.

[DiapDealer]

Originally Posted by jhowell

I have been assuming that you can just leave out the cover image altogether and that Amazon would automatically insert the separately uploaded marketing cover as the internal cover. Hitch implied that is the case earlier in this thread.

That very-well could be the case in non-KDP situations. But to my knowledge, there is no separately uploaded marketing material with the KDP process.

[slowsmile]

@jhowell...I've just looked at the Amazon Kindle Publishing Guidelines(section 4.2) and here's what it says about the cover image:

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 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.

Seems to be saying that a cover image should be added to the book content but this is not very clear. Depends on what they mean by "book content". Not sure whether "book content" refers to adding the Amazon product image to the epub on KDP upload or does it mean adding a cover page/image directly to the epub. It also does not mention whether the above rule applies to Word docs or epubs or both.

[DiapDealer]

Originally Posted by slowsmile

Seems to be saying that a cover image should be added to the book content but this is not very clear.

It's very clear, but only if you stop conflating PAGE with IMAGE FILE.

An image FILE (PNG, JPG, GIF, etc) for use as a book cover should be included (manifested) in the epub.

A cover PAGE (xhtml) should not.

The conversion process knows which image to use for the cover by checking the META 'name="cover" ' entry for the manifest id of the image in the 'content="<insert manifest id here>" ' attribute/value pair.

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

The above identifies the image with the opf manifest id of "cover.jpg" as the image to be used for the book's cover. In this case, the manifest id is also the file name, but that doesn't have to be the case. It could be any valid id value. For instance:

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

would point to an image entry in the manifest list with the id "cover_img" that should be used as the book's cover. Something like:

<item id="cover_img" href="Images/img0001.png" media-type="image/png"/>

EDIT: or in the case of EPUB3, the manifest property "cover-image" would be added to the proper image's manifest "item" entry.

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

[Hitch]

Originally Posted by DiapDealer

That very-well could be the case in non-KDP situations. But to my knowledge, there is no separately uploaded marketing material with the KDP process.

Diap:

Some years back, at least 3-4, Amazon changed things so that any cover uploaded that is baked into the MOBI/ePUB/Whatever will *not* display as the marketing image on the Zon website. Instead, the image that is uploaded separately, in the "Content" section of the Bookshelf, is used for the website marketing image. More importantly, vis-a-vis this discussion, it is placed into the uploaded book, replacing any cover that is already in the MOBI/EPUB/whatever, or creating the cover placement, if one is not there.

Amazon said that they had such issues with DIY authors and Word files that they changed the entire process so that the uploaded Marketing image would be inserted into the uploaded ebook, overriding or supplanting any cover already there.

This brilliant decision, on their parts, resulted in the dreaded "double cover" issue, that affected Word files uploaded with cover images embedded therein, and MOBI and ePUB files that were uploaded with a cover.xhtml page therein.

The newer method of mobi-building, using the cover IMAGE, not the cover FILE, so marked in the metadata and the Guide, works to create a MOBI that only has a single cover, despite Amazon's best efforts to "help."

HTH,
Hitch

[DiapDealer]

Thanks for clarifying, Hitch.

Suffice to say that any add-on KDP validation process should probably be checking for meta entries (epub2), or manifest properties (epub3) to see if the mandatory cover image is indeed present. And it should be checking the guide section for a cover semantic to see if an xhtml cover page is present that Amazon advises against.

That's how I'd handle the cover page/image section of any KDP validation plugin I was creating for Sigil, anyway. I'd probably create an output plugin that did the checking and removed the xhtml cover page if present. That way content creators could maintain one main source epub, and could generate a KDP-compliant version on demand, so-to-speak.

[Hitch]

Originally Posted by DiapDealer

Thanks for clarifying, Hitch.

Suffice to say that any add-on KDP validation process should probably be checking for meta entries (epub2), or manifest properties (epub3) to see if the mandatory cover image is indeed present. And it should be checking the guide section for a cover semantic to see if an xhtml cover page is present that Amazon advises against.

That's how I'd handle the cover page/image section of any KDP validation plugin I was creating for Sigil, anyway. I'd probably create an output plugin that did the checking and removed the xhtml cover page if present. That way content creators could maintain one main source epub, and could generate a KDP-compliant version on demand, so-to-speak.

Hi:

Which is, almost to the letter, how we work at my shop. :-)

Hitch

[theducks]

Originally Posted by slowsmile

@DiapDealer...Yes, I am still confused by what you say.

On the one hand you are saying that a cover PAGE(aka cover.xhtml??) should not be included in an epub that you uploaded to KDP. Then you say that a cover IMAGE is allowed.

But isn't the cover IMAGE situated in the cover PAGE ??

So how can you not have a cover PAGE while at the same time have a cover IMAGE in an epub??

Unless I'm missing something, you seem to be inferring that the cover IMAGE is not situated in the cover PAGE but is entirely separate from the cover PAGE. I admit that I am having a problem with that.

How can a cover IMAGE be present when the cover PAGE is not there??

Easy. It is flagged as "unused" by the typical EPUB check.
EPUB2 requires BOTH the page and the Image have the 'cover' flag

[slowsmile]

Thanks to everyone -- particularly Diap and Hitch -- for clarifying what "cover image" refers to. I understand it now -- the term "cover image" also includes all cover refs in the opf directory. My mistake was to assume that the term "cover image" only referred to either the cover image file ref in the cover page or the cover image file itself in the Images directory.

DiapDealer said:

"Suffice to say that any add-on KDP validation process should probably be checking for meta entries (epub2), or manifest properties (epub3) to see if the mandatory cover image is indeed present. And it should be checking the guide section for a cover semantic to see if an xhtml cover page is present that Amazon advises against."

This plugin only checks epub2 files. If an epub3 file is checked with this plugin you will get an error. I also use the "name=cover" metadata ref(like Doitsu's Epubcheck) to check for the presence of a cover.

Currently the plugin only checks for the toc and start read point in the epub. If there are less than 2 refs in the guide, a warning will be shown. And if there are more than 2 refs in the guide(not including the cover ref) another warning is shown.

DiapDealer said:

"That's how I'd handle the cover page/image section of any KDP validation plugin I was creating for Sigil, anyway. I'd probably create an output plugin that did the checking and removed the xhtml cover page if present. That way content creators could maintain one main source epub, and could generate a KDP-compliant version on demand, so-to-speak."

I originally wanted the plugin to be a validation plugin and would prefer to keep it that way. This plugin just reports problems in much the same way as Epubcheck. I also think that the warnings and errors generated by the plugin should be enough for the plugin user to be able to fix all reported problems in much the same way as Epubcheck.

One last question. When the user removes the cover page from the epub, should he/she also remove the cover image file from the Images directory in Sigil as well?? If the answer is that it should also be removed then perhaps I should also add another plugin check to ensure that the original cover image file is also removed from the Images directory. My understanding is that the amazon product image will automatically be added to the epub Images directory on upload to KDP. Please let me know if I've got this wrong...

[Hitch]

Originally Posted by slowsmile

<snippage>

One last question. When the user removes the cover page from the epub, should he/she also remove the cover image file from the Images directory in Sigil as well?? If the answer is that it should also be removed then perhaps I should also add another plugin check to ensure that the original cover image file is also removed from the Images directory. My understanding is that the amazon product image will automatically be added to the epub Images directory on upload to KDP. Please let me know if I've got this wrong...

No. You leave the cover image in the images folder, otherwise, you'd a) run into issues with having assigned the cover metadata to it, and b) Kindlegen uses that image to then create the "cover image" in its proper place, inside the built mobi.

Right?

Hitch

[slowsmile]

@Hitch...Yup, got it. Much thanks for clarifying.

The plugin currently gives a warning if the cover page(cover.xhtml file) is present in the epub. There is also no need for a guide cover ref check because when you remove or delete the cover page in Sigil, the guide cover ref will also automatically be removed in the content.opf.

[DiapDealer]

Originally Posted by slowsmile

@Hitch...Yup, got it. Much thanks for clarifying.

The plugin currently gives a warning if the cover page(cover.xhtml file) is present in the epub. There is also no need for a guide cover ref check because when you remove or delete the cover page in Sigil, the guide cover ref will also automatically be removed in the content.opf.

My reason for suggesting the check for the guide reference was to find the actual file name of any xhtml page that had been marked with the cover semantic. Merely checking for the presence of a file named "cover.xhtml" is insufficient in my opinion. A "cover.xhtml" file could exist that wasn't marked with the cover semantic (and thus does not qualify as a cover "page" that warrants a warning/error). And because any xhtml file with any name could be marked with the cover semantic and should qualify for the warning/error.

The mere existence of a file named "cover.xhtml" itself is not the relevant factor in whether or not a warning/error should be generated. It's the existence of a file that is marked as a cover page (with a reference entry in the guide section) that determines if Amazon's "No xhtml cover page" rule is being violated or not.

[slowsmile]

@DiapDealer...To check the presence of the cover page, the plugin currently uses the opf metadata cover id to confirm whether the epub has a cover page or not but I've already realized that there is a problem using that method. So I will certainly do as you suggest and change it to search for the guide cover reference in the next plugin update. Thanks for that suggestion.

[DiapDealer]

Yes. The meta cover entry can help verify that the cover image that is supposed to be there, is. But it's the reference entry in the guide section that can help determine if a cover page that isn't supposed to be there, is (by providing the file name to look for).