Is it Time to Stop Making eBooks for Older Kindles?

I got the following question late last week, and after rolling it around in my head without getting a definitive answer I decided to throw it open to the #eprdctn crowd on Twitter (as well as anyone else who makes ebooks) and see what the general consensus was.

One of my readers who is also digital publisher is thinking about making Kindle ebooks in the new KF8 format. We've been able to do that for some months now, so this isn't new. But the reader wants to know if it is safe to make ebooks without worrying about how they look on older devices.

Hi there, do you know of any stats/data that indicate how many K3 and older devices are still in use? Or, how many owners have upgraded and no longer use the older ones? I'm trying to figure out how much I need to support mobi7 lack of features vs KF8.

I'm assuming that most every Kindle ebook you make will have an Epub version. The nice part about making a Kindle ebook in KF8 is that you can effectively make it look almost identical to the better quality Epub ebooks, rather than creating 2 different quality ebooks from scratch or limiting the the Epub version to features supported by the older Kindle format.

The downside of making ebooks in KF8 is that when Amazon automatically converts them to the older Kindle ebook format, the ebooks could end up looking bad. For example, KF8 supports much prettier formatting options as well as embedded fonts. If you make a Kindle ebook which uses those better features and then try to view it on an older Kindle like the K2, the result will look like a poorly converted ebook. It might even result in a confusing or unreadable ebook.

Question: Are there still enough older Kindles in use to justify formatting the Kindle ebook for them?

Against: All of Amazon's current Kindles and Kindle apps now support KF8, and they are the majority of Kindles in use. The last Kindle which doesn't support KF8 was the K2, which came out in 2009, and the Kindle DX, which has been discontinued.

For: Supporting the older Kindles usually won't cause a problem. Yes, it limits you from using some of the features which can make your ebook look prettier, but do you really need to use those features? Aside from a couple experimental projects I have only formatted novels, myself, so the simpler formatting found in the older Kindle format was more than enough.

Nate Hoffelder

Nate Hoffelder is the founder and editor of The Digital Reader: He's here to chew bubble gum and fix broken websites, and he is all out of bubble gum. He has been blogging about indie authors since 2010 while learning new tech skills at the drop of a hat. He fixes author sites, and shares what he learns on The Digital Reader's blog. In his spare time, he fosters dogs for A Forever Home, a local rescue group.

Related Posts

19 Comments

Charles Kravetz (charlie-tca)16 October, 2012

For many of us, the Kindle Keyboard is the last unit we purchased. It allows more accessibility than any of the newer units. If I need the speech capability, it’s there. the newer kindles/nooks/kobe readers took this away. Why is technology taking away features needed by the disabled of the world? It really does not add much to the cost to keep these features. It does add a whole big market waiting to upgrade their old machines, though. Until someone announces a new ereader that lets me read, I will stay in the old Kindle. If that means someone loses ebook sales, well, maybe if they lose enough sales, they will wake up.

Those who worry should first do a little research, I should say. A KF8 formatted file is basically a pack of two mobis: a v6 or v7 and a v8. That is why – hear the complaints – a mobi file output by Amazon’s command line Kindlegen is twice the size an old fashioned prc or mobi (v6). When you load a new mobi on your device, if it happens to be a Kindle Fire, say, it will use all the nice formatting candy you allow it to use. If you load it on a K3, it will use some of it (publisher’s fonts, e.g.), and if you load it on an even older Kindle, it will only use the stripped down, old mobi formatting. I think what one needs to be aware of, though, is how and what you target with your formatting. I think it is okay to have a fancy, sophisticated layout and typography version for the Fires and new Kindle lines, that in fact degrades gracefully for the older lines. Correct me if I’m wrong here 😉

Yes, that stripped down version is the one which lacks the embedded font, nicer formatting options, and some other features. It does not always degrade gracefully, and another way to look at this discussion is as pondering whether we should care.

BTW, I don’t make KF8 ebooks with KindleGen. I use calibre because it lets me generate just a single ebook, not the huge multi-ebook file you mention. Also, there is a tool which will let you split that huge multi-ebook file into separate KF8 and Mobi ebook files.

Nate, yes, you are right, however the question is whether to support old Kindles or not. My answer is that it is not really an issue: careful formatting can sell an ebook for all ranges. True, with the old mobi, you’ll lose drop caps, or fixed layouts, even other nice formatting – but it does not mean it would not work, i.e. older devices are supported, too.

Splitting the file, if you are about to sell your ebook through Amazon, will not work – they accept one file, so you’ll then need to decide which one you wish to upload and sell. If you do not split the file, it is the user’s device that decides the issue 😉

And you are still missing the point. This is not a technical question about ebooks; I’m debating a design philosophy.

If I make an ebook which uses the full abilities of KF8 it will look like crap on older kindles. Should I accept the fact it will look like crap or should I instead skip the nicer features and make a less sophisticated ebook?

Edit: But as Paul makes clear down the page, it is possible to support multiple styles inside the one ebook uploaded to Amazon.

Calibre is great for personal consumption, but KindleGen is necessary as a publishing tool. I’m not sure of anyone who uses KindleGen for personal use…they’d have to be pretty damn techy (it only works at the command line). Although, Calibre is not a good option for creating the .mobi file that gets uploaded to KDP due to the strange formatting and metadata it introduces. Luckily, Amazon doesn’t slap authors/publishers with that delivery fee on the massive .mobi file that contains BOTH the KF8/MOBI formats . They calculate it based on one or the other.

The way the .mobi file gets made (the one you upload to KDP) includes both the KF8 eBook and the older MOBI eBook. You can only have common HTML for the eBook, but you can change the styles (in the CSS) for the different formats. Therefore, you can have something like a floated dropcap that will render on KF8-supported eReaders, but would render differently on the older MOBI formats (like a big bold letter that is not floated as an example). Floating is one of those things not supported on MOBI. You can also do stuff like a make a gradient background for a block of text on KF8, but on the MOBI it would be indented, or perhaps no styling at all. Embedded fonts are totally safe for use and won’t cause any readability issues on the MOBI, assuming you know what you’re doing in the stylesheet.

We try to support both KF8 and older MOBI formats at our company, since many readers still use devices that have only MOBI support. If The reason this isn’t common knowledge is a lot of publishers are still using one-click eBook creation solutions and technical documentation on making eBooks is terrible. I don’t know of any software solution that will automatically do the stylesheet correctly. You sort of need to build the EPUB from scratch (HTML, CSS, and XML) and then convert it with KindleGen. It’s a rough learning curve and most smaller publishers and independent authors don’t have the time or inclination to learn this stuff. I guess that’s why we’re in business.

While the Kindle devices are pretty much going away from MOBI, the Kindle for iOS still doesn’t support KF8. I might be one of those schmucks who likes to read books bought from Amazon on their iPad, but I know I’m not alone. A good eBook sold on Amazon should support all formats until the MOBI dies like support for Internet Explorer 6 did, which might be a few years off still.

Thanks for the detail about the CSS. That was an option I had not considered. I didn’t know you could effectively build 2 distinct versions of the ebook inside the one output file. It’s far less work than the work involved in building 2 ebooks from scratch.

But embedded fonts can present an issue depending on how they are used. What if you are using several embedded fonts in a technical manual to indicate different data categories? The fonts will be stripped out of Mobi ebook, leaving a confusing mess. An alternative would be to use different stylings, but I suppose that can be dealt with in the CSS.

And FYI: I make ebooks from scratch (HTML, CSS, and everything) using an old copy of Mobipocket Creator. I only use KindleGen when it is time to combine the parts.

I think the iOS apps support the fixed layout KF8, but not reflowable KF8. Weird huh? Not sure why Amazon did this.

For the eBook, you can only have one chunk of HTML (content) but the style sheet can apply different declarations to the different devices. You can do some tricks like hide certain pieces of the HTML on the older MOBI formats, but make it show up on KF8, and vice versa. It’s a bit of a pain, but right now it’s the only option. For technical data, I had the same problem in my last book. I basically sectioned off the technical stuff with a gray background for the KF8, but added a black bar and above and below for the MOBI formats. Seemed to work out okay.

We have the luxury at our company just doing what the client says. But the design conundrum for publishers/authors to do a lot of support for MOBI or go all in with a fancy KF8 that might not work well on a MOBI is definitely something to think about, especially for non-fiction or complex eBooks.

I didn’t know you made eBooks from scratch. Very cool. I hope you do a geek post sometime, because we’re always looking for new tricks. But that might scare off some people, haha.

Thanks, Nate, for your excellent blog. We always keep up with the latest eBook news and opinions at your place for our small business. It really helps us know what’s going on. You rock, man. It’s 11:20pm Bangkok, so good night.

Late entry here but: This is EXACTLY how I do it. I mark up the book as an EPUB with HTML/CSS. I make a separate CSS sheet with @media query just to tweak .mobi and if needed I do another for kf8, landscape, etc. Then I KindleGen the book and there you have it. 1 book for all readers! Now, If Amazon/IOS would upgrade to kf8…I would stop making .mobi books unless explicitly asked to do so.

With my production process, I found that mobi7 required some changes in semantics for epub to make things look passable on Kindle 1s and 2s. You can use css media queries to differentiate between mobi7 and kf8, but that doesn’t really let you change semantics of course.

I would love to know what percentage of Kindle users are downloading ebooks onto Kindle 1s and 2s.

Overall, I found that ebooks produced today require much less time and can be produced for maximum compatibility. But is it worth returning to previously published ebooks to upgrade them to take advantage of KF8 features? That’s the question…

It all boils down to money, but let me mention one clear win: the first mobipocket had abominable support for indices. If an index is important, you probably should lean towards the KF8 format.

There is one reason why I would stick with support for the older Kindle format for a while longer: non-Kindles. Strip the DRM from Mobi7 file and rename it as .mobi and it’ll be readable on FBReader, Coolreader, and many non-Kindle eink readers. Don’t, and they’ll have to run a conversion from KF8 to epub 2.1. Not sure how important this might be but… (shrug)

The real problem is that one XHTML + CSS for all formats/readers is a utopian chimera, while at the same time creating a different XHTML + CSS for each format is impractical madness.

Amazon’s kindlegen’s purpose is supposed to solve this: you create 1 single book with all bells and whistles, where you also apply revisions and fixes, and then output dumbed down versions for different specific readers based on programmed rules instead of hand tweaking.

Yet, it all fails because the dumbing down from XHTML + CSS ?HTML~3 that kindlegen performs is based on buggy and undocumented rules producing undocumented targets, and its use is limited to very specific targets.

Thus, why kindlegen would be far more interesting if it was opensourced, where we could write our own global and per-book conversion rules, far more accurate and rich than kindlegen’s current ones, based on hierachies of HTML elements, CSS classes or even selectors not yet widely supported by any HTML/CSS engine.

Such a tool would allow ebook producers to work exclusively on a master markup targetted for a theoretical 100% standards compliant bug free engine, and convert it, using comprehensive rules and exceptions, to a myriad of less capable formats (not just Kindle! EPUB2&3, platform dependent ebooks or whatever was based on HTML!) with very little overhead or worries (far less than having to hand tweak for each platform, as we have to do now).

I do not know of anything else remotely closer to that than kindlegen, and Amazon seems to have no intention of opensourcing it, neither of properly documenting the mobipocket format, unfortunately.

elmimmo, I just wanted to mention that my workflow involves writing source in docbook XML and then using docbook XSL stylesheets to output xhtml. There are limitations and challenges to this workflow/toolchain, but one definite advantage is that you are creating your source only once and then choosing your output method. (PDF, epub, epub2, etc). Not useful for fixed layout and making a semi-decent PDF is challenging, but other than that, it works. (I describe some of the advantages on the comment I made herre: http://www.imaginaryplanet.net/weblogs/idiotprogrammer/2010/11/ebookepub-production-secrets-tips-tricks/#comment-408187 )

I produce my book in docbook, write some XSL to customize the epub output, and use XSL customizations or profiling to produce a Kindle-friendly epub.

I have less of a problem with Kindlegen than I do with the proprietary mobi and kf8 formats themselves. Things would have been a lot easier if Amazon just adopted the standard. Then, all we would need to do is to tweak the css a bit for each ebook channel.

Hey guys. Many of us loyal kindlers do not pop for a new gadget each time they appear on the scene. Many of us are economically challenged by our dire economic conditions. That is partly why I personally jumped on the Kindle bandwagon in the first place back in Nov. 2009 JUST 35 months ago. More and cheaper books via the free and inexpensive offers, putting out occasionally for a new best seller, getting Kindle e-books from library sites. We would have to give up buying unreadable or weirdly formatted new titles for our trusty refurbished KDX1’s (used by vision challenged father or K2 (shared with my student daughter), we will not run out to replace our readers willingly, as they work perfectly, cost over $200 each way back when. (Both with that valuable free 3G we love and don’t want to replace, especially at the higher price options on the newer Kindles.) I would be interested in Amazon’s take on how many older Kindles are still in use and worry that you are jumping the gun on a pretty high population of avid readers. Just adding my thoughts from a older reader.

I can see that some discerning authors will want very specific formatting for their books especially if they are writing reference books with tables and images that need careful organising. But the vast majority of authors will simply require that their books display in a clear, consistent form and will not be concerned particularly if multiples of font type are not available. Fiction authors don’t tend to have too many (if any) images either and when they do, they can be centered in the page in an appropriate size which still works for .mobi type formatting. Which leads me to believe, that when it comes to many publications, they can be uploaded as a single file that works well as an AZW and which can of course be read by the newer Kindles as well. So why stress about continuing to use mobi under those circumstances, there seems little point until the older Kindles die a natural death; which may take many years. Far easier, as someone else mentioned I think, to continue to use mobi unless specifically requested to do otherwise.

I think most readers of ebooks would adhere to that as well, especially if they thought they might have to pay more for books simply so that they could choose a specific font for example. I am not just talking about transfer costs of larger files here, professional designers come at a price and that cost also needs to be passed on somehow, assuming an author actually makes any sales. But that is another subject completely 🙂