New Kindlegen, new Kindle Previewer, new Kindle guidelines…
Ahem. The days of Kindle Previewer being a quick, lightweight download appear to be over; hardly surprising given that KF8 requires a much more complex rendering engine than the old Mobi format.
My advice for the time being is to consider what aspects of KF8 will genuinely benefit your project, and to keep portability (both of your book’s source files to ePub, and of your Kindle files to older devices that will never see KF8 support) very much in mind.
Amazon has announced the replacement for its existing Kindle (Mobi) format; the list of supported HTML and CSS tags is here. You can also sign up to be notified when the publishing tools and guidelines are released.
Plainly, Amazon is moving toward something that’s much closer to ePub, which lends further credence to the idea that the reason for the “Kindle Bloat” I discussed in a previous post, is that new generations of Kindle software and tools will make use of the ePub information that’s incorporated into the Kindle (Mobi) files.
What about the effect on creating ebook files that are portable between ePub and Kindle? On the face if it, the closer that Amazon gets to supporting the same features as ePub does, the easier the portability job should be — and the fewer compromises ebook designers will need to make, when creating content that will work on both platforms.
However, a possible fly in the ointment is the position of older Kindle devices, which apparently are not going to be upgraded with the new Kindle 8 capabilities…
“Kindle Fire is the first Kindle device to support KF8 – in the coming months we will roll out KF8 to our latest generation Kindle e-ink devices as well as our free Kindle reading apps.”
… which begs the question of the fate of previous-generation devices that aren’t in line for the upgrade (I guess because they are not capable enough). Will the Kindle 8 standard have the option to embed an old-fashioned Mobi file, for these older devices to use? If so, designers may still have the opportunity (and the headaches it will doubtless take!) to create ebooks that can adapt to the oldest Kindle devices — though clearly there comes a point with complex layouts that this must become impossible or impractical due to diminishing returns, and previous-generation Kindles must be left behind.
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.