[KDPValidator] Validate epubs for KDP upload only

[Doitsu]

Originally Posted by slowsmile

But I tried an experiment. In a valid epub, I changed the cover file refs from "cover" to "noddy" in the metadata, manifest and spine. And when I ran Epubcheck the epub passed without any problems at all which surprised me.

The file id defined by the content="xxx" attribute does not matter at all as long as it matches the cover image manifest id, because Kindlegen will look for a <meta> tag with a name="cover" attribute.

[st_albert]

Originally Posted by slowsmile

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

Well, I've learned by now not to argue with you, but I'll just say this:

First, in these discussions it is crucial to keep in mind the distinction between the "cover page file" which is the .xhtml file in the book browser Text directory (hereafter called the "cover page file"), and the cover image itself, which is typically a .jpg file in the book browser Images directory (hereafter the "cover image").

It is the Amazon KDP guidelines themselves, not I, which forbid the use of the cover page file. They say:

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.

This seems to be in direct contradiction to this part of your code (beginning on line 367 of cutils.py)

   # cover.xhtml -- check for bad file position
    fnames = []
    for _, href in bk.text_iter():
        file_name = os.path.basename(href)
        fnames.append(file_name)
        
    if cover_fname != '':
        if fnames[0] != cover_fname:
            message = BAD_COVER_FILE_POS
            options.RESULTS.append(['error', '', 0, message])

which is looking for just such a file. In fact, if it finds one, it should warn about THAT.

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.

I have no idea how you concluded that I suggested that, unless you failed to distinguish between the cover image and the cover page file. What I said was:

Actually, in the epubs that I intend to convert to mobi with kindlegen, I don't have an xhtml cover page at all.

See the difference?

Lastly, I'll note that, according to the KDP guidelines, the metadata entries discussed above are mandatory, whereas the cover guide element is optional. That was the basis for my caution about relying solely on the guide element to identify the cover image.

Albert

[slowsmile]

I'm afraid that I can't quote you a Kindle guideline ref for my belief that it doesn't matter whether you have a cover image file in your epub or not on conversion to mobi -- because KDP will add or replace your cover image with the Amazon product image anyway. I actually got that information from Hitch, who is a Kindle recommended professional formatter, on the KDP forum some years ago. So if you don't believe what I say abut the cover image file then perhaps best to ask her when you get the chance. Hitch has also stated that Kindle is terrible at updating their own guidelines docs to align with any new formatting changes. That's fairly well known too.

And here's another Kindle guidelines oddity. Kindle does not recommend using SVG cover images for KDP upload in its Kindle Image Guidelines. The Kindle Image requirements still clearly state that only jpeg or tiff cover images should be used. And yet plenty of people on this forum successfully and regularly upload svg cover images in their epubs(KF8 only) to KDP without any problems. Why doesn't the Kindle guidelines say anything about using SVG cover images being used in epubs?? And what's even more peculiar is that you cannot upload an SVG image as your product image -- that's not possible. So if you put an SVG cover image into your ebook, how is it that the SVG cover image in your ebook is able to override the Amazon product image being inserted into your ebook?? Nothing is said about that either in the Kindle Guidelines. I'm still scratching my head over that one. And if you don't believe what I've said about SVG cover images being used in Kindle ebooks then you should perhaps download Granny Grump's The Legend of Sleepy Hollow from Amazon and have a look at the svg cover image for yourself.

If you still believe that KDP requirements or guidelines docs are perfectly adequate and always tell the truth then try finding the the Kindle requirements for creating a perfect Look Inside version of you ebook. That should be in their doc guidelines, right? You won't find any Kindle guidelines on how to assure a perfect Look Inside anywhere on the internet. I learned most of what I know about formatting the Look Inside correctly by trial and error. Hitch has also mentioned that Look Inside formatting guidelines have always been 'Top Secret' and would never be revealed to the general public. Don't ask me why. Ask Hitch.

[jhowell]

Originally Posted by slowsmile

And if you don't believe what I've said about SVG cover images being used in Kindle ebooks then you should perhaps download Granny Grump's The Legend of Sleepy Hollow from Amazon and have a look at the svg cover image for yourself.

I am curious about this. Can you provide a link or ASIN?

[Doitsu]

Originally Posted by jhowell

I am curious about this. Can you provide a link or ASIN?

AFAIK, GrannyGramp does not use SVG cover images; she uses JPEG images in an SVG wrapper. I.e., she uses the default cover image code generated by Calibre and Sigil. Her books also contain the cover image metadata entry recommended by Amazon.
Since her cover pages contain no text they'll be ignored by KindleGen anyway. As far as KindleGen is concerned, it doesn't really matter whether she uses an SVG wrapper.

[slowsmile]

@jhowell...Sorry, my mistake, The Legend of Sleepy Hollow by Granny Grump is not advertised on Amazon -- the epub version is available for download on Mobileread.

But the above still proves my point about gaping inaccuracies and lack of updates in the Kindle Guidelines because if you load and test the above epub in Kindle Previewer 3 it will happily convert to mobi and display the svg cover image without errors. This Kindle behaviour under test does not adhere to the current Kindle Cover Image Guidelines which says that only jpeg and tiff cover images can be used for conversion to mobi.

[slowsmile]

@Doitsu...I'm not sure what you are saying in your post. What I'm talking about is the accuracy of the Kindle Guidelines(re: cover image formatting) -- not how Granny Grump formats her cover image using an svg wrapper. As I've already said, if the Kindle Guidelines does not include svg as a viable cover image format then why is GG's ebook displayed using svg formatting without any errors after conversion with KP 3? The point I'm making is that the Kindle Guidelines(see the link in my last post) doesn't mention svg as a viable format for Kindle ebook covers. So why are there no cover image format errors shown when you test and convert GG's ebook with KP 3?

[st_albert]

@slowsmile re: inaccuracy of KDP guidelines:

"It's a mystery!"
-- Shakespeare in Love


Albert

[slowsmile]

@Doitsu...
"AFAIK, GrannyGramp does not use SVG cover images; she uses JPEG images in an SVG wrapper. I.e., she uses the default cover image code generated by Calibre and Sigil. Her books also contain the cover image metadata entry recommended by Amazon. "

I'm not sure if this is a viable check, but after I converted GG's ebook using KP 3 and saved it as a mobi I then converted it back to an epub using KindleImport. And when I checked in Sigl, the svg cover image wrapper was still there. SVG cover image wrappers are not allowed in mobi according to the current Kindle Cover Image Guidelines. In fact, they are not even mentioned.

[slowsmile]

st_albert...Yeah, I agree completely. Kindle Guidelines are very frustrating. It's one of the reasons I'm now bald. Still got my nails though...

[DiapDealer]

Originally Posted by slowsmile

As I've already said, if the Kindle Guidelines does not include svg as a viable cover image format then why is GG's ebook displayed using svg formatting without any errors after conversion with KP 3?

Because quite simply put: you don't seem to understand the difference between an SVG image and a non-SVG image wrapped in SVG image tags. GG's books validates with no errors because it does not include any images in the SVG format.

As far as the rest goes: I think you're taking a few liberties with regard to the Kindle Publishing Guidelines. That's certainly your choice. But you should probably make it clear that your plugin is not really any kind of true KDP specification validation. It is a plugin that checks for what you personally have decided is good enough for your own KDP uploads.

Regardless of if they're "outdated" or bit ambiguous in spots, it's a bit of a stretch to ignore Kindle Publishing strictures simply based on anecdotal "works for me"s (in a KDP Validation Plugin). Validation is almost never about what "might sometimes work with no problems." It's about setting a baseline that people can then choose to ignore at their own peril--knowledgeable in the fact that "seems to be working" isn't at all the same thing as "valid."

[Hitch]

Originally Posted by slowsmile

I'm afraid that I can't quote you a Kindle guideline ref for my belief that it doesn't matter whether you have a cover image file in your epub or not on conversion to mobi -- because KDP will add or replace your cover image with the Amazon product image anyway. I actually got that information from Hitch, who is a Kindle recommended professional formatter, on the KDP forum some years ago.

You've either misunderstood or misstated what I said. At the time, I was talking about the fact that someone could upload an ePUB (or HTML file, etc.) with NO cover, because you can upload a cover image which Amazon will, indeed, insert into the resulting MOBI file in the Cover image position. However, William, I have said, very loudly, for years, that a cover.html or cover.xhtml file should absolutely NOT be used. It does not function well with Kindlegen. To this day, the Dreaded Double Cover situation exists from Word files at the KDP--I see no reason to assume that it's been resolved, 100%, for other source files.

We make our files as does St. Albert--we build our ePUB, get a working, ePUB-checked copy, and then we remove the cover.xhtml page/file. We leave the meta pointing at the cover, as ewll as the Guide (for the Go To functionality).

Honestly, we haven't made a MOBI from an ePUB with a cover.xhtml file in at least 5 years, possibly longer. As long as Amazon has been inserting the covers "for" the publishers.

So if you don't believe what I say abut the cover image file then perhaps best to ask her when you get the chance. Hitch has also stated that Kindle is terrible at updating their own guidelines docs to align with any new formatting changes. That's fairly well known too.

Yes, that's certainly true, but that's why it's helpful to test, test test. We do it through sheer volume, really, but...

And here's another Kindle guidelines oddity. Kindle does not recommend using SVG cover images for KDP upload in its Kindle Image Guidelines. The Kindle Image requirements still clearly state that only jpeg or tiff cover images should be used. And yet plenty of people on this forum successfully and regularly upload svg cover images in their epubs(KF8 only) to KDP without any problems. Why doesn't the Kindle guidelines say anything about using SVG cover images being used in epubs??

Due to KF7, quite simply.

And what's even more peculiar is that you cannot upload an SVG image as your product image -- that's not possible. So if you put an SVG cover image into your ebook, how is it that the SVG cover image in your ebook is able to override the Amazon product image being inserted into your ebook?? Nothing is said about that either in the Kindle Guidelines. I'm still scratching my head over that one. And if you don't believe what I've said about SVG cover images being used in Kindle ebooks then you should perhaps download Granny Grump's The Legend of Sleepy Hollow from Amazon and have a look at the svg cover image for yourself.

I don't know which one is GG's, but always happy to look.

If you still believe that KDP requirements or guidelines docs are perfectly adequate and always tell the truth then try finding the the Kindle requirements for creating a perfect Look Inside version of you ebook. That should be in their doc guidelines, right? You won't find any Kindle guidelines on how to assure a perfect Look Inside anywhere on the internet. I learned most of what I know about formatting the Look Inside correctly by trial and error. Hitch has also mentioned that Look Inside formatting guidelines have always been 'Top Secret' and would never be revealed to the general public. Don't ask me why. Ask Hitch.

Very simply, again, because the LITB is in a current state of flux. I doubt that Amazon itself is sure enough of the LITB functionality and predictability to put out Guidelines on it. Not quite sure what on earth the LITB has to do with putting a cover.xhtml file in an ePUB destined for Kindle, as really, as I mention, nobody has done that for the last 5 or so years. {shrug}

Hitch

[slowsmile]

@DiapDealer...
"Because quite simply put: you don't seem to understand the difference between an SVG image and a non-SVG image wrapped in SVG image tags. GG's books validates with no errors because it does not include any images in the SVG format."

Just to try and be clearer, whenever I talk about svg format I'm really talking about using svg wrappers around jpeg images. Perhaps I caused some confusion by saying svg format but my only reason for doing that was to save some space. After all, this is a blog where abbreviations and short cuts are commonly used to save space. In future I will always refer to such images as images with an svg wrapper to help avoid any misunderstandings.

"As far as the rest goes: I think you're taking a few liberties with regard to the Kindle Publishing Guidelines. That's certainly your choice. But you should probably make it clear that your plugin is not really any kind of true KDP specification validation. It is a plugin that checks for what you personally have decided is good enough for your own KDP uploads."

It might seem that I'm taking liberties with the Kindle Guidelines but I have also given some good examples of gaping information holes and lack of doc updates in the Kindle Guidelines in my posts above. But, like you say, I guess that it's really up to each individual indie author to find this out for himself. Personally I agree with st_albert -- the Kindle Guidelines is a poorly maintained document.

"Regardless of if they're "outdated" or bit ambiguous in spots, it's a bit of a stretch to ignore Kindle Publishing strictures simply based on anecdotal "works for me"s (in a KDP Validation Plugin). Validation is almost never about what "might sometimes work with no problems." It's about setting a baseline that people can then choose to ignore at their own peril--knowledgeable in the fact that "seems to be working" isn't at all the same thing as "valid."

You're not wrong about the "works for me" part. But if you can point me to the detailed Kindle Guidelines for correctly formatting the Look Inside version of my ebook, I would be very grateful for that information. Unfortunately, the Kindle Guidelines gives no information at all on how to properly format the Look Inside version. That information should be in the Kindle Guidelines because it is important. Why isn't it there? So all I can do is try and find a successful way to do it for myself which is what I've done over the years. And if people think that my info is taking a bit of liberty and a load of bunk then that's fair enough. My only intention is to pass on some useful information to other authors/formatters that is not in the Kindle Guidelines. But really, the best person for you to ask whether the Kindle Guidelines is up to date and accurate is Hitch. She has also, on occasion, expressed some considerable frustration with info holes and lack of guideline updates in the KDP forum. So best to ask Hitch because she's the real expert in this area.

[slowsmile]

@Hitch...Thanks for clarifying everything -- very timely. I have also noted your info that all uploaded epubs must not contain a cover image. Hopefully my old brain will remember that info and not forget. And apologies to st_albert for any wrong cover image info. I'll also have to change the plugin wrt cover image checks -- as Hitch and st_albert have advised -- as soon as I can.

[DiapDealer]

Keep in mind that I'm not suggesting you should comply with everyone's wishes in every aspect. But where your chosen practice does seem to deviate from the Kindle Publishing Guidelines, why not add a warning to that effect?

If you want to personally allow an (x)html cover page, just think about adding a warning that the guidelines recommend against this practice. Then the user (including yourself) can make up their own mind.

Ex: "Your epub includes an xhtml cover page (name.xhtml). The Kindle Publishing Guidelines indicate this shouldn't be done."

Rather than make your personal preferred practices generate nothing but silence for everyone, generate warnings for anything questionable (or errors if the guidelines are specific). What "may" or "may not" work shouldn't really have anything to do with validation. There's plenty of discussions about where there's wiggle-room in the Guidelines. So there's really no need to silently pass "gray areas" in a validation program.

You could also add preference settings that users can use to quell warnings/errors they've chosen to ignore.