Book covers displayed on product pages in Amazon’s Kindle store are emblazoned with a special logo: the words “kindle edition” appear below the book cover, and a small image of a Kindle reader is superimposed onto bottom-right corner of the cover itself. This superimposed image obscures part of your cover, so when designing book covers that might some day be used for Kindle editions (including covers that are originally intended for use with paper editions or ePubs) you might want to keep important graphical elements away from this bottom-right area. Alternatively, you might prefer to create custom Kindle covers that take this issue into account.
You can probably judge the obscured area by eye, but if you want to set up guides showing its extent, you could always find a suitable cover image on the Kindle store — one that has the same aspect ratio as your book cover — and then crop it appropriately, enlarge it to match your cover, and paste it into a layer within Photoshop or whatever equivalent program you use. The pasted cover then becomes a template from which you can position guides to show exactly where the “unsafe” area is.
We generally create ebook covers at 600×800 pixels, and the unsafe area is then approximately 82×146 pixels.
If you’ve worked with many ePubs and converted them with Kindlegen while paying attention to file sizes, you might well have noticed that the Kindle files are much larger than the original ePubs — typically around twice as large. It turns out that Kindlegen stashes a copy of the original ePub sources inside its output file, which explains the doubling of size. Unfortunately, this can lead to super-sized Kindle files, particularly in heavily-illustrated works, since images get duplicated along with everything else.
To see how you can strip out this bloat, head over to the Mobileread forums, in particular to pdurrant’s post about his excellent Kindlestrip Python script and AppleScript wrapper. Note that if you don’t already have Python, you’ll need to download and install it before you can use this script.
For many people (me too!) the immediate instinct will be to run the above script on everything, in order to minimize file sizes, transfer/bandwidth requirements, and space on our customers’ Kindle devices. However … consider why Amazon might have designed their conversion tool to force the inclusion of this source information in its output file; they hardly did so by accident. Are they planning to use the stashed information in future versions of their Kindle hardware and software, to enable future Kindles to get closer to the layout of the original ePub? Will future generations of Kindle support ePub directly, and try to find ePub files inside Kindle files? If so, then clearly there’s a trade-off involved in the decision of whether to strip the file.
Personally, I’d consider heavily illustrated works as clear candidates for stripping, since the duplication of images is so costly. And, if you’ve designed your ePub to be fully “Kindle-friendly” then maybe there’s little benefit to leaving the extra information in place, since the basic Kindle version will already be fine. However, for Kindle files that suffer by comparison to their ePub originals, or where the overhead is negligible, you might want to consider leaving the bloat in place, in the hope that it might come in useful one day.