Calibre and Kindle, Not a Good Match

UPDATE 010314: I wrote this article before I did any real research into Calibre. Considering the vast number of hits this blog post is generating, I knew there was a call for information about how to convert a Word file to MOBI in Calibre. I found a fix and I wrote a series of posts about it. Part 1 (Styling in Word), Part 2 (the HTML file) and Part 3 (Conversion in Calibre). It’s not a quick fix (or magical), but it’s not difficult either.

Don’t get me wrong. I like Calibre. It’s quick, it’s handy, and it has an attractive screen display that I far prefer over Adobe Digital Editions or the Kindle Previewer. Since I don’t have a device capable of reading EPUB files, it’s also useful for checking the formatting on files I create for others.

What it’s not good for? Converting EPUB files into MOBI files for commercial purposes.

Having seen some horrendously broken ebooks that had been converted through Calibre, I have long suspected that Calibre was the wrong tool for the job. I assumed it was user error, a problem with the source file and/or the html, and if the formatter did a really good job with the initial file, Calibre wouldn’t muck it up.

I was wrong. The problem is with Calibre.

Squish3I converted an EPUB file to a MOBI file with Calibre. I then took the exact same file and converted it with KindleGen via the Kindle Previewer. The above screenshots are the results. Same page, same settings, same device (Kindle Paperwhite).

Squished lines.

In the recent ebook formatting contest, I saw squishy line spacing in every single ebook that had been converted via Calibre.

So maybe the problem lies in the subtle differences between the html coding for EPUB and MOBI. I ran a file I had made specifically for Kindle through Calibre. Squishy lines. I took that Calibre-generated file and ran it through KindleGen. Squishy lines.

Could Amazon be taking care of the problem? I downloaded samples from the contest entries. Squishy lines.

Why does Calibre do this? I have no idea. It just does.

Why is it a problem? Because for many readers, myself included, Kindles (and other ereaders) make reading comfortable again. My eyes are old, plus I spend all day in front of a computer. My eyes are tired. With the Kindle I can change the font, adjust the font size and change the line spacing for optimal comfort. Squishy line spacing is hard on my eyes. When I try to read an ebook that I can’t adjust for my comfort, I get irked. When I’m irked, that author/publisher ends up on my Don’t Bother list. (Your future sales, folks)

There are alternatives to Calibre. If you are converting a Word or html file, use MobiPocket Creator. If you have a simply formatted file, it will generate a prc file you can upload to Amazon and it will work. If you have an EPUB or html file, you can use the Kindle Previewer (converts with KindleGen). A warning about the Kindle Previewer–what you see is not always what you get. Trust but verify and test your files on an actual device if you can.

55 thoughts on “Calibre and Kindle, Not a Good Match

    • It appears not. Since I’m not a Mac user, take with a grain of salt, but I would recommend you save your files as html (if you are using a word processor) and convert the html file through the Kindle Previewer OR download the Sigil program (it’s free) and use it to make EPUB files which can be converted through the Kindle Previewer. I’ll be writing a post later about how to use Sigil to make sturdy Kindle books.

      Mac users, jump in. What is the best alternative to Calibre for you?

      • I have a Mac with Parallels (which allows me to run Windows and Windows-based software on my Mac). One of the many things I do is convert eBooks into various formats and upload them to Kindle, Smashwords, Kobo, and a few other sites. I do use Calibre to make my EPUB and MOBI/PRC files. When uploading to Kindle, I use the PRC (simply a copy of the MOBI file with the extension changed to PRC). Kindle has not notified me of any issues uploading this format, and I have been doing it for several years now (at least 20 files a month). I have used Sigil to make EPUBs and it is time consuming. The EPUBs I make with Calibre open in Sigil already perfectly formatted.

  1. Ever since Calibre added the ability to tweak an ePub, I like to start with an ODT file (which is how I do most of my writing anyway) then convert to ePub with Calibre. From there, I tweak the stylesheets and such until it looks right, then dump it into Kindle Previewer to get the mobi file. Probably not the most straightforward method, but I like the control it gives me.

    Also, if you want an On PC ePub reader, Adobe Editions is pretty good for it.

    • Hi Joseph. Does your method cause squishy lines in the converted MOBI files? Just curious.
      By the by, I think Calibre has a better display on the computer screen display than Adobe. 😀

      • I don’t have one of my books handy to check, but for the most part I’ve found that any format problems I encountered could be fixed by fiddling with the stylesheets file when I tweak the ePub. I know there’s a “line spacing” attribute that I recently had to adjust to avoid overly spaced lines. Presumably the same value could correct under spaced lines. The problem is, you’re essentially editing raw HTML, which I’ll admit somewhat defeats the purpose of using a program in the first place.

      • I just downloaded one of your books. No squishy lines. This is good information. Tells me it is the conversion part of the process that is the problem. Carry on! 😀

  2. “Tells me it is the conversion part of the process that is the problem.”

    Conversion from what to what? HTML to mobi? I used a Macbook Pro to convert from HTML to mobi for both Valknut and Rose. Did you see a squishy line problem with those? (I think you may have Valknut, at least.) If you don’t see a problem, then maybe the Mac version of Calibre is fine but the Windows version has a problem. This wouldn’t surprise me.

    • Squishy lines. Sorry. It’s Calibre across the board. Even for Mac users.

      I am not going to dismiss the notion that the problem might be new. There have been updates to Kindles recently, and one of them I absolutely despise. I’ll be posting about it in a few days.

      • Really! I don’t notice it on my iPad, though I will check again now that I’m aware of the problem.

        Calibre is nice because you can do all kinds of formats without having to load a file into multiple pieces of software. I would like to figure out a workaround.

  3. Calibre is great for an online library. No trouble there. It’s just not right as a conversion program for commercial use. I don’t think there is a single program that does it all. Which sucks, but that’s life.

    I recommend using Sigil, but with some modifications for the Kindle versions (resets, cover, opf, etc.) Take the EPUB and convert it with KindleGen, and no problems.

    • Have you done a post on Sigil? I’m not sure what you mean by “resets, cover, opf, etc.”

      Also, Calibre constructs a TOC easily. How about Sigil, KindleGen, or MobiPocket?

      • I’ll be doing a post on that stuff later. It sounds more technical than it is.

        As for the ToC, well, there are some problems in Kindle-ville, and I am trying to figure out what is going on.

  4. Hmm. I have never used Calibre to take an epub and make a mobi file–I use a base HTML file and convert it to mobi and epub separately. I just checked a recent file conversion on my old Kindle, and I get the same line count as you do for your KindleGen example. I’m using Calibre version 0.8.34 — could it be a combination of the version of Calibre, KindleGen, and the Kindle software itself?

    • There is an incompatibility somewhere, but I don’t know enough about programming (okay, I know nothing about programming) to tell you why or what exactly is going on. All I have are the results I can see. My experiments with it tell me it’s not something the formatters are doing, so while there may be some convoluted tweak a user could do, I don’t know what it is. The best I can recommend is to NOT use Calibre as a conversion tool for MOBI files. There is better software available, and it’s free.

  5. I’m following up on your suggestions, but I want to note that this post defined what you meant by “squishy” lines. Now I know what to look for.

    I’ve been experimenting with formatting ebooks, and I’ve come to understand that you have to learn the conversion path that will work for you. I’ve heard from people who use InDesign to EPUB to MOBI and read of people who rejected InDesign. (I’ll add your MobiPockets suggestion to my future research work).

    The issue that’s unsettled in my mind is how bad the “squishy” lines look. The example above looks no different from a book, and boosting the font size makes it easier to read.

    • I come at formatting from a reader’s point of view. For me, ereaders are all about comfort. Anything that interferes with the user’s ability to adjust the screen for their comfort is less than desirable. The squishy lines aren’t a deal killer, but they are irksome. They force me, the reader, to choose between squinting or kicking up the font size, and larger font sizes have their own problems.

      As for InDesign, it’s a whole different subject. I don’t use it, but my partner does–to create print layouts. The problems I see with InDesign for ebooks are pretty much the same problems I see with Word. The program is far too overpowered for ebooks. Somebody who fully understands what is going on ‘behind the scenes’ and truly understands how ereaders work, can use Word or InDesign to make an ebook that works the way it’s supposed to. Everyone else is going to have problems. Or rather, their readers will have problems.

  6. Calibre does however work quite well the other way – I create the MOBI using KIndle Previewer from a clean HTML /OPF files. Once I have the MOBI running it through calibre and adding the cover gives a clean and non-squishy ePub. Seems to work with less hassle than Sigil.

  7. This is just a difference in spaces between lines. In the world of TeX (a typesetting program designed by Donald Knuth that is still used in a lot for technical journals), this was known as baselineskip: the amount of whitespace between the baselines. If you had a 10pt font and a baselineskip of 20pt, your text appeared double-spaced. As someone else noted, the version on the left looks more line a normal book, where the font was typically 10pt and a baselineskip of 12pt. You obviously prefer a larger baselineskip. That doesn’t make Calibre broken, it just means that you don’t like the default baselineskip. As noted above, this can be changed by editing the CSS stylesheet used for the book.

    • I hear what you’re saying, Hunter, but that’s not exactly what is happening. Kindles have three line spacing options. At its lowest, it’s ‘single-spaced,’ at medium it’s 1.5 spaces, and at wide it appears double-spaced. The books in question do shift their line spacing. Unfortunately they go from ‘too-tight’ (where the letters actually touch) to ‘single-spaced’ to about 1.4 spaced. Changing the css doesn’t help. I tried different files and kept coming up with the same problem. It’s something going on between Calibre and the Kindle.

      • OK. I should have said that I was replying without actually having a Kindle. I was just basing my comments on your image. Sorry!

  8. “squishy lines” = tight leading in typesetter speech … and I was under the impression that Amazon no longer supported MobiPocket and discouraged its use in favor of Kindlegen.

    • You’re right, Maggie. Amazon has not kept it up to date fully, compared to KindleGen. That said, it does have its uses. If a person has a Word file that has been meticulously cleaned and formatted according to the Smashwords style guide, or a simple html file, MobiPocket will convert it into a serviceable file. It will work better than running it through Calibre.

  9. The line-height CSS property for MOBI/KF8 eBooks is sort of like a sleeping bear: you shouldn’t go poking it with a stick. Calibre is a great tool for personal consumption but it has major issues in the way it handles CSS, typically with non-human friendly class names like “calibre1” and “calibre2”. It usually specifies a line-height declaration on every single class by default and this borks everything up. In Calibre’s defense, Amazon’s technical guidelines for how Kindle devices render CSS are horrendous. For author’s looking to use an automated conversion, they should check out Jaye’s recommendation on Sigil (which is free).

  10. Jaye, I pointed Kovid Goyal of Calibre at this writeup, and this was his reply…

    … In the first place if they want to compare kindlegen and calibre, they need to convert to azw3 not mobi in calibre.

    • Hi Karen, please tell Mr. Goyal that in the first place I wasn’t comparing KindleGen and Calibre, I was pointing out a conversion issue. 😉 And if I was comparing them, it would be as screen readers, which Calibre would win, hands down.

      I did use the same files I was fiddling with for this blog post and converted them with azw3 and loaded them on my Paperwhite Kindle, and the line spacing issue was no longer an issue. The files work fine. I haven’t yet seen what happens when those types of files are uploaded to Amazon. If anyone has an ebook they have converted to azw3 with Calibre, then put that particular file up on Amazon, please let me know. I’ll get a sample (or buy the book if it looks really interesting)

  11. Jaye, I just did a comparison myself of the MOBI file generated by Calibre (the one you commented on in your “contest”) and a version produced by Kindlegen, which I just tried for the first time. I don’t have a Kindle device, so I’m using Kindle Previewer and the Paperwhite device.

    The line spacing issue is addressed as you recommended. Alas, when Calibre generates a MOBI output it creates the TOC from scratch for the file, and you don’t supply one going in (in HTML). Kinglegen doesn’t do that. When I insert a full TOC (as I do in my HTML file that goes to EPUB), it treats it properly from a link perspective, but the device doesn’t recognize it as a TOC.

    Now I was aware of the existence of this issue, more or less, but Calibre doing it properly meant I didn’t have to deal with it directly. How can I get the device to recognize the TOC (something about an NCX or OPF file? And how do I update those files?) I hate the feel of multiplying tools just to get the line spacing better.

    BTW, you commented that I had some problem with my TOC in my submission, but I don’t know what you mean. The TOC seemed fine to me in the Kindle Previewer.

    Also, BTW, the line spacing issue you identified, very visible in the Paperwhite, is not visible at all using the Fire emulator in Kindle Previewer. Or in the older Kindle. It seems to be specific to the Paperwhite.

    • Just to add insult to injury, the TOC is visible in the “NCX View”, even though it doesn’t show up when you press the TOC button on the Kindle Previewer. No doubt this is some issue with that “guide” statement I’ve been reading about, bleary-eyed…

    • First a word for our good friends at Amazon: The Kindle Previewer is one of the most deceptive programs on the internet. I have seen files that display perfectly in the previewer that turned out to be badly broken on the actual devices, and I have seen files that appear to have thoroughly blown formatting that actually render perfectly on the actual devices. What it does do is render images faithfully and its navigation guide is reliable. Everything else, take with a hefty grain of salt. ( I should start a side service of testing Kindle files…)

      Also, something bizarre is happening with the ToCs and Kindles. It’s taken me a while to notice because I hand build my ncx files to make sure things go where they are supposed to go. With the contest and so much close inspection, I’m seeing over and over again that the ToCs are not being recognized on the Paperwhite, which they should be, because the Keyboard is recognizing them. I suspect this has to do with a device update where some brainchild decided listing the ToC in the Go To feature was redundant or something. Or it could be something else entirely. I need to investigate.

      Karen, as for your wobbly links. What happens is, I click a link for Chapter One. Instead of taking me to the chapter header for Chapter One, it takes me to the first word in chapter one. So at first glance, it appears to have landed me in a random spot in the ebook. If I page back, the proper first page of Chapter One shows up. So the links are going to the right place, just not the exactly right place. Easy fix. Go into your html version and tag the beginning of each chapter with a div id.

      What I do (and I am going to try to do this so wordpress doesn’t treat it like html, so bear with me) is at the very “top” of each chapter/section, I tag it with

      {div id=”chap1″}& nbsp ;{/div}
      The brackets should be greater than/less than characters and the ampersand and semi-colon are closed up.

      Now when I link back, it goes to that “space” at the very top of the page and the entire page is displayed.

    • I’m not exactly sure, but I suspect the synching has to do with files that are in the “cloud” as opposed to doc files that you’ve loaded manually onto a specific device. So no cloud, no synch.

  12. I’m confused. I convert an HTML file into both EPUB and MOBI using Calibre. Wouldn’t a change in the code make the lines less “squishy” if that’s a problem? For me, both my EPUB and my MOBI files look the same as far as line spacing goes. I follow Guido Henkel’s method for formatting. So all this talk of KindleGen and Sigil and opf and what what you is all Greek to me. 🙂

    • Best I can determine, Rob, is that the problem lies between a Calibre MOBI file and the Kindles. It’s not something the formatters are doing. The fix is to NOT convert your file into a MOBI file on Calibre, but instead convert it into an AZW3 file on Calibre. I tried it, no squishy lines in the Kindle book.

  13. My best success has been to convert HTML to Epub in Calibre, then create the Mobi file from the Epub file with KindleGen. The KindleGen docs suggest that the resulting Mobi file will be readable on any Kindle, but I only have a Fire to test on. Can anyone comment on this?

    • If it’s working for you, then stick with it. I wouldn’t trust the Kindle Previewer too much, though. It doesn’t show the line spacing issues I see on my actual devices. Since you’re familiar with html, try the new Calibre EPUB editor. You can adjust the page declaration (one of the stylesheets) and fix the guide in the content.opf, too. That’ll take care of the majority of problems.

      • Yes, it took me a while to realize how inaccurate the Kindle Previewer is. Things that looked horrible in it were fine on the Kindle Fire. As for the Clibre Epub editor, I’m trying to make the process as automated, as possible so I’ve created a PHP file to essentially rewrite the HTML file and its CSS before Caliber gets it. All I have to do in Calibre is add the cover and convert to Epub.

        It’s working well except that Calibre is sometimes confused by complex CSS and assigns the wrong classes to some spans. Then again, it’s a technical book with 42,000+ lines of HTML code with at least 75 styles, so it’s a wonder that Caliber handles it at all. The Sigil Epub conversion of the book has many problems.

        BTW, the code in the DOCTYPE section (and maybe elsewhere) of your Part Two article contains both curly quotes and un-rendered entities, so it can’t be cut-and-pasted and used as is:

  14. I’m a bit late to this thread. I’ll try to explain some of what your seeing, but I’m relying on my memory for some details, and might get a fact or two wrong,, (corrections welcome.)

    Mobi file is a container, which can hold different file formats. (Including, Mobi version 6, the old files, KF8, the new format, and even epub.)

    By default, Kindle Gen includes all 3. The important part, however, newer Kindle devies (Kindle Keyboard with up to date firmware and newer) will display the KF8.

    By default, Calibre converting to Mobi converts to the old V6 files. Those had much more limited formating options. (I was under the impression that line height wasn’t even something you *could* change. I might be wrong about that part though.)

    Converting to AZ3 is how you tell kindle you want the New KF8 format file. KF8 is much like epub, (HTML files with standard CSS formating,) and therefore supports line height, the same ouput as you put in the input. (With the notable exception that the Kindle devices do not let you reduce line-height to less than 1.2em, which messes up many epub drop caps that are formatted with a >1 line height.

    • Better late than never, Rashkae. 😀

      The problem with conversion to AZ3 is that while it displays beautifully on most Kindles, Amazon won’t accept the file for distribution. So that puts pubs back to square one.

      As for line height, all three generations of my Kindles now handle the line-height command with relative ease. 110% is my default setting when I style a book, and I have no problems going as high as 140% (display-wise). Amazon does have a nasty trick about putting extra leading between paragraphs in iOS mode. Whether that actually shows up on iPhones and iPads, I do not know, but it looks pretty bad in the Kindle previewer.

      As for drop caps, I don’t use them for Kindles because not all of them accept the text-top command, and without it the drop caps tends to float and look ridiculous.

      The Calibre epub editor does work and pubs who need to use Calibre for conversion should invest some time in learning how to use the editor.

      • Oh, I would never suggestion using Calibre Mobi conversion to distribute over Amazon. (obvioulsly, my knowledge on this topic is out of date.. I tought epub to KindleGen was the only path for that.)

  15. Frustrated with Calibre on both mac and pc ; Atlantis is perfect for conversions from .doc/.docx , on mac KindleGen works great

  16. I have just been running into this exact same problem, thanks for the advice! I shall try Mobi-Pocket Creator. Can I ask, when I have uploaded my manuscript to kindlegen using kindle previewer, all of the images are microscopic. You have to click on them to enlarge them. Is this usual?

    • I am not sure what is going on. When I have to use Word for an ebook, it’s a “generic” version for Smashwords and I don’t put images in those. BUT, I have read that images need to be “locked” in Word so that they render properly. Not sure how to do that, but some fooling around in Word should solve that for you.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s