Book lovers will have noticed that JK Rowling has just released a new novel, and it is neither a children’s book nor connected with the Harry Potter universe. Casual Vacancy has polarized opinion; it’s a triumph for some, an author overreaching herself for others, and a sizeable minority who choose to leave online reviews complain of the book’s vulgarity. I guess a wide range of opinions was inevitable, though I am pleased for her sake that a large proportion of the more neutral commentators seem to have at least something positive to say about her book.
What attracted my eye were not comments about the story, but about the eBook formatting. For specific combinations of Kindle or Nook reader device and firmware (firmware is the software that tells the device how to display the book) Casual Vacancy was unreadable. You simply could not set a font size to a setting that was practical to read.
There were a lot of angry comments online, initial confusion from Amazon customer support, and the finger of blame pointed at the publishers for clearly not bothering to test the book. (Here’s a summary from The Atlantic) which led to an admission of guilt from Hachette, the book’s publishers, and a fix the following day. (If you buy the book now, you will be fine. If you had the problem, B&N/ Amazon customer support can guide you to the fix).
Should Hachette have done a better job? Absolutely! You might not have heard of them, but you will have read books from their imprints. They are the second largest publisher in the world, with sales last year of over $10billion. You would think they would have done a better job at checking such a key release. I feel sorry for JK Rowling, and for disappointed readers.
And yet, I do have some sympathy for Hachette. Actually — no — not for Hachette but for the individuals who worked on the project, some of whom may well have been asked to collect their belongings and leave the building for the last time. Take my comment that Amazon customer support had no idea what the problem was — well, they should have done! Because the symptoms seen in Casual Vacancy have been seen in hundreds, probably thousands, of other Kindle titles since the spring. I’m sure the individuals on customer support were trying their best; they didn’t know what the problem was, but Amazon as a company did.
Letting Hachette off the hook sounds ridiculous, but I’m going to explain why I feel some sympathy in this article by letting you in on the wacky world of building eBooks. Normally I would say: do a shabby job and you deserve to be out on your ear. But I reckon that building eBooks is not always as easy as you might think, and almost certainly not as easy as it will be in a few years’ time.
I had similar comments directed at a book I once built for the Nook. 1-star reviews because the book wouldn’t load up at all. As soon as I heard of this I looked into the problem. It didn’t take long to find that hundreds of people had the same problem and they were having problems with a seemingly random selection of books from a wide range of publishers. In fact, what the victims had in common was not the book title, but their Nook device itself. The cause was a faulty software update that Barnes & Noble had rolled out that didn’t work on some older Nook devices. It made no difference which books you had in your library, but if you were unlucky some would fail to load. Of course, as a reader seeing some books load and some not, I would naturally blame the publisher. People did! But there was nothing we could have done to build the books in a way that would have been immune from this problem. By the time I was aware of the issue, Barnes & Noble had already rolled out a fix to their faulty software.
As for tiny fonts on the Kindle, I have certainly seen something that sounds suspiciously similar.
When you write the software for an eBook you have many ways to specify how big something should be, whether a margin or a font size. In fact, it is a rag-tag mess that represents the evolution of HTML and CSS, the languages used in eBook code. You could choose to specify font size as small, medium or large, as a % of the parent font size, as smaller or larger than the parent font. You could decline to give any information about font sizes and hope you inherit a sensible default. Or you could use a unit called an ‘em’, which in theory should be the same as using %, but in practice, isn’t. You could use ‘absolute’ units such as cm, pixels or… the unit you are probably familiar with from word processors… points.
If you’re having difficulty getting to sleep, try this as a typical online discussion about setting font sizes. It’s talking about web pages, but they use the same html/ css software language as eBooks.
What I find interesting is to see there are over two-hundred comments for an article written in 2008. It was written 4 years ago, and the last comment was posted just 4 days ago as I write this. And if you look closely, the answers are changing as the web browsers change. When the article was written, pixels were considered an absolute unit; now many web browsers will scale items sized in pixels. With the Kindle 3, 4, 5, DX and Fire, points are scalable units too. Or they were.
And so it is with eBooks. You can get a book on CSS and read up what all these various size units mean in theory, but that means very little in practice. What the reader actually sees on the Kindle screen is up to the Kindle software and your book’s code getting in a huddle with your user settings, and hashing out a compromise about which of the device’s font sizes it will choose to display.
I bought my first Kindle device 18 months ago. Until last Friday, it had seven font sizes. That’s it. There was no point in specifying 0.875ems or some such — that precision is an illusion — it simply mapped onto fonts 1 through 7. And carefully setting margins in ems didn’t work either. Your alignment and spacing would look wonderful in your web designer or InDesign, but the Kindle device would round everything up to the nearest whole number of ems.
Then on Friday, my Kindle upgraded itself, from software version 3.3 to 3.4 If I had bought Casual Vacancy on Thursday, it would have read fine on my device. If I had bought it on Friday, it would have been unreadable because the software update meant my Kindle now displayed Kindle books in a different way, and a way that the Hachette eBook coders hadn’t accounted for.
I myself had a problem with a book that worked fine when I built it, but between building and publication there had been an update to the Kindle 4 and Kindle Touch devices that rendered it unreadable, and with what sounds like exactly the same problem as Casual Vacancy.
A lot of people are saying Hachette didn’t test the book. I think a more likely explanation is that they didn’t re-test the book. I worked for 20 years at a software organisation delivering software that was expected to be maintained for many years. We would always take a lot of care in thinking about which configurations we would test against. In fact, our customers would expect us to tell them exactly this sort of information before we would issue a release. If a new version of Oracle or SQL Server, or Windows had come out, our customers would expect us to say whether we supported that new version.
My guess is that this book was tested by Hachette but several months ago, and was not re-tested against new Kindle software versions as they came out. When we made a software release at my old company I would encourage everyone in the organization to spend a morning installing and running the new release. I called it Bash Testing. With all the secrecy about Casual Vacancy, I imagine the exact opposite happened, that the book was kept securely locked away — during which time the book quietly stopped working.
Should the Hachette coders have anticipated this problem? Actually, yes, because it’s a problem that’s been known about since the spring. The question of culpability can get quite heated online, but it’s a bit of eye-opener if you don’t know anything about how eBooks get made. It comes down to the question of how to set font sizes in the code.
For small and self-publishers, Amazon suggest four main ways of making Kindle books, two of them assume you will set font sizes using points, and two of them made no assumptions about how you would specify font size (although Amazon changed its guidance this year to suggest those two solutions should use %’s as the unit). To get the problem you need to specify font sizes in points, but it also depends on which tool you used to build your book, which Kindle software version is reading the book, and possibly which phase the moon is in (okay, I still don’t know precisely which combination brings up this problem). The most compelling guess that I’ve read on the internet is that someone at Amazon who wrote the Kindle software update got pixels and points confused. You specify 12 point text but the Kindle displays it 12 pixels high. That’s unreadable.
Even though Amazon has always recommended that eBook designers shouldn’t try to set font size for the body text (because it might override the reader’s settings) they have always encouraged you to do so with headings and other text. Units such as ems or %’s are theoretically scalable, so it’s a fair argument that eBook designers should always have used these measures because they were always more likely to be robust, even though Amazon’s own coding samples used points to set sizes. So I don’t believe this change was deliberate from Amazon, because there was a point earlier this year when one day you could build a book that followed Amazon’s coding guidelines to the letter and it would work fine, and the very next day that same book would not work for readers who had received the new Kindle software update.
Whether you regard that as a bug or not, Amazon have certainly known since the spring that hundreds, possibly thousands of Kindle titles have fallen foul of this problem. I know less about the Nook problem, but it may well be a repeat of the same story over at Amazon/ Kindle.
None of this is to excuse publishers who put out books that do not work. And that includes myself.
But I feel sorry for JK Rowling. And I do feel a little sympathy for the Hachette people who probably built the book months ago, tested it, and thought they had done a good job. I can almost hear them say: “But it worked on my machine!” I used to hear that a lot from coders in the early 90s, but it doesn’t cut it in a professional software team these days. Hachette Livre — or whoever you use to make your books — welcome to the real world of software development.
Help! How do I fix my book?
I know some Kindle self-publishers read this blog, so if you have a touch of the Casual Vacancies with one of your own books, here’s the fix for Kindle.
I’ll assume you’ve got the html file that you saved from Word (using filtered html file type) AND a text editor. On a Windows PC this would be Notepad. Don’t use Word or another word processor to edit the html
Start Notepad (or your choice of text editor) and open the html file for your book.
At the top of the file you should see a `Styles’ section. You should find one entry to correspond to each style present in your Word document. The styles called `h1′ and `h2′ etc. correspond to the heading1, heading2 styles, and there might be a style called `p’, which is very important because it gives settings for the default paragraph style. This style section is your CSS.
For this problem, you want to take out anything that says something like
For the `p’ paragraph style and your `normal’ and `body’ styles you don’t want ANYTHING for font-size. Simply delete the font-size line (but make sure the style definition still ends with a `}’ character.
For heading styles you DO want to set the font size, but need a different way of stating it. Instead of something like `font-size:16pt;’ change to a % value such as `font-size:160%’. The % gives the multiple of the default font size, and the default font size is whatever the users set on their Kindle.
That might be all you need to do. But it is also possible that you have set some styling directly in the main body of your html file. Do a search for the text ‘font-size’ If you see that anywhere, change the pt size to % (although you will probably find this a lot in the code for page breaks — I’m not convinced you need to change code for page breaks).
HOW TO TEST
As a simple test, once you’ve saved the html file from Notepad, you can open the html file in your internet browser. That’s just a quick first look, though. Always download the .mobi file from the Amazon KDP edit book details screen once you’ve uploaded the book. This problem currently shows itself on Kindle software versions 3.4, 4.1, and 5.1 The Kindle Fire works fine.
If you get the hang of simple html style editing, you might want to handle paragraph indents too. If you want paragraphs to not have a first-line indent, go to the corresponding style entry in the html file and add
AN EASIER WAY?
If coding is not your thing, you could use a third-party tool. Calibre is one. You could convert from html to mobi and upload the result. This might fix your problem, but it might not. It may be worth a try.
Lots of people use Calibre, including Smashwords, to make Kindle books, although the results don’t match Amazon’s coding guidelines, and Amazon sometimes reject books built through Calibre (probably because the Calibre developers have had to guess how the Kindle header is supposed to work and not guessed correctly. If this happens to you, re-covert through Calibre but this time send the output to a debug folder. Run Kindlegen over the contents of the ‘processed’ folder and Amazon will accept it).