Archive for the ‘ Formatting ’ Category

zencover I honestly had not expected how much work it would be, putting together my book Zen of eBook Formatting. After all, I had the blog tutorial to build upon, and yet, it took me many months to flesh out the final book, add in all the little details and additions, and tweak it to make sure it is as accurate as I can make it. Part of it had to do with the fact that eReaders have turned into a sea of incompatibility.

eReaders have turned into a sea of incompatibility

While the original “Take Pride in your eBook Formatting” tutorial is still every bit as relevant and applicable today as it was when I first published it a few years back, as soon as you want to go beyond the most basic formatting features, you get caught up very quickly in the morass of device limitations and quirks.

With each new device generation new problems are being introduced, and considering that we are now looking at fifth or sixth generation devices, one can quickly get lost in the maze of dos and donts of eBook formatting.

I am not pointing fingers here because every manufacturer contributes to the problem. Apple with its incompatible ePub implementations in iBooks for one, Amazon for other limitations and countless firmware bugs, Barnes&Noble for a different set of firmware bugs. Each of them making it harder for eBook formatters to navigate these waters and create reliable products.

Switching a font face, for example should be a completely trivial thing. According to the HTML standards which underly both the MOBI and EPUB format, you should be able to switch fonts anytime on a block level. Sadly, this is not true in the world of eBooks.

Typically a code snippet like this should work fine on any device, assuming we have a span style called “newfont” that sets a different font family.

<p>Let’s <span class="newfont">switch the font</span></p>

Sadly, all of Apple’s iBooks devices and software do not follow this standard. Not even a snippet like the following one works.

<p class="newfont">Let’s switch the font</p>

iBooks does not recognize font family settings in <p> and <span> elements, which is completely inconsistent with HTML standards. It is not a mere oversight, however, because Apple has been dragging this problem through all iterations of iBooks, since its inception years ago. One can only wonder what Apple’s software engineers are thinking.

If device manufacturers would stick to the standards in the first place, hacks like these would not be needed

I found that oftentimes I have to double-stitch solutions, nesting different solutions, so that if one doesn’t work there is always a fallback. The work-around to fix this particular problem is to use another block-level tag in order to pass the information to iBooks.

<p>Let’s <span class="newfont"><cite class="newfont">switch the font</cite></span></p>

While this is not the most elegant solution, and purists will scream out at the misuse of the <cite> tag here, the reality of things is that as eBook formatters we currently cannot afford to be purists. We need formatting challenges solved and in this case <cite> addresses a very specific problem. If Apple would stick to the standards in the first place, hacks like this would not be needed.

I found that the same kind of double-stitching is sadly needed if you want to strike out text, as in draw a line through it. It is not a very commonly used text feature, but if you need it, it is imperative that it shows up correctly.

Instinctively you would use the <strike> tag, which has been part of the HTML vocabulary since its inception. <strike>, however, has been discontinued with the HTML5 standard, and as a result there are now eReaders that no longer support it. They require the <del> tag instead, which, quite by coincidence, is not supported by some older devices, of course.

As in many cases, double-stitching the solution is the way to go for me and whenever I have to strike out text, it will look like this.

<p>This is how you <strike><del>strike out</del></strike> text.</p>

Once again, not the most elegant solution, but as you format eBooks, you will have to get used to seeing things such as this more and more often. As I said, with every new generation of eBook devices, the number of these types of inconsistencies will grow and the need to find and apply band-aid solutions will sadly grow with it.

If you want to find out more about basic and advanced eBook formatting techniques, make sure to check out my new book Zen of eBook Formatting, which details all the necessary steps to create professional-grade eBooks.

The past months I kept myself busy completing a new book on the subject of eBook formatting, as many of you may know. I am happy to announce that the book is finally available! For only $5.99 you can now benefit from the years of experience I have had as a professional eBook formatter, learning the ins and outs and the tricks of the trade I have applied to many hundreds of eBooks from New York Times bestselling writers and indie authors alike.

zencoverZen of eBook Formatting is in the same vein as my “Take Pride in your eBook Formatting” tutorial series, but it goes way beyond that, as it is vastly expanded and updated. In the book I am taking readers through the entire workflow that I am using every day for the projects I am working on for my clients. In an easy to understand manner—I hope—I am not only explaining the steps, but also explain why these steps are necessary and why I do things the way I do them. The result is a tutorial-style self-help book that is chock full with examples, tips and coding snippets.

Having formatted well over 500 eBooks at this time, I am covering the entire process, from the basic manuscript cleanup, to the basics of HTML and simple markup, all the way to advanced techniques that allow you to add an incredible amount of polish to your eBooks without necessarily sacrificing device compatibility.

Just to give you an impression of the breadth of subjects I am covering, here is the Table of Contents for you.

Table of Contents

  • Preface
  • Introduction
  • 1 – The Road to Right
    • Understanding eBook readers
    • Why you should not use a word processor
    • The road to Right
    • Tools of the trade
  • 2 – Data Structure
    • HTML
    • CSS
    • Prepping your style sheet
  • 3 – Cleaning Up the Manuscript
    • The Power of Em
    • Time to clean up your manuscript
    • Fixing up styles
  • 4 – From Word Processor to Programming Editor
    • Nice, clean and predictable in HTML
    • Paragraphs are the meat
    • Fleshing it out
    • Dealing with special characters…the right way
    • A word about fonts
  • 5 – General Techniques
    • Centering content
    • Images
    • Image resolution
    • Chapters
    • Typography and Layout
  • 6 – Advanced Techniques
    • Chapters
    • Initials
    • First-line capitalization
    • Formatting inserts and notes
    • Formatting emails and text messages
    • Image blocks with byline
    • Custom fonts
    • Linking to the outside world
    • Lists
    • Backgrounds and Color
  • 7 – eBook Generation
    • eBook formats
    • Meta-Data
    • The Cover
    • The TOC in the digital world
    • Calibre
    • More control with XPath
    • KindleGen
    • Error-checking
  • 8 – eBooks Outside the Box
    • A Word about Fixed-Layout Books
    • Preparing for Smashwords
  • Parting Thoughts
  • 9 – Appendices
    • Chart of named entities
    • Resources
  • About the Author
  • Also by Guido Henkel

The key to me, when putting together this book, has been to make it possible for anyone to create an eBook that has a professional level of presentation. Too many authors use shortcuts to create eBook version of their manuscripts, flooding the market with broken and sub-par product that leaves a bad taste in readers’ minds, when in fact, applying a little bit of discipline could elevate them from that riffraff and make their books like a million bucks.

Zen of eBook Formatting is targeted at all those of us, who care about their books, not only the words we wrote, but also that they are presented to the reader in a clean and professional manner that works on as many eReaders as possible. Hopefully, with Zen of eBook Formatting at hand, this goal will be within reach for many more authors.

Grab your copy of the book an Amazon now!

Over the past three years or so since I first published my “Take Pride in your eBook Formatting” series of tutorials here on the site, a lot of people have asked if I would make the tutorials available as an eBook as well. For a number of reasons I never created an eBook on the subject, in part because I simply could not spare the time to put it together. If I wanted to release something like this as an eBook it would clearly have to be cleaned up and expanded upon in order to warrant any sort of price tag attached to it.

Well, over the past few weeks I took a look at the tutorials again and I have finally decided to create an eBook on the subject of eBook formatting. Since my tutorial series has become the de facto standard in the industry and is being used by countless authors to prepare their books for the market, I felt it was finally time to take it to the next level.

As I pointed out above, creating a mere reprint of the blog tutorials is not at all what I have in mind. Instead I have spend these past weeks reworking the instructions to give the entire process a clearer structure, but also to add many of the topics and elements that I did not touch upon in these tutorials. The tutorials were designed, really, to get people started, but with a book I feel it requires a lot more in-depth information to be of any value at all. It needs to be more complete, and as a result, the book will consist of a section with basic techniques that will get you to your first eBook, much the way the tutorials did, but in addition, the book will contain a section with advanced techniques in which I will describe how to achieve certain effects and how to handle certain formatting challenges that pop up every day, but require a bit more explanation and additional skill. Naturally, I am trying to keep it very accessible still to ensure readers can easily follow the instructions and examples.

Over the years I have seen many blogs that touch upon the subject of eBook formatting and some of the posts I came across were frightening—in the sense that they promoted techniques that are highly unsafe. While they achieved the goal for that particular individual, oftentimes the approach was nothing short of reckless, using very specific device capabilities without pointing out to the user that this behavior is not supported by other devices or that it can actually create unexpected behavior and lead to page corruption. Clearly, these authors never had the time to fully explore the techniques they were proposing, or didn’t have the foresight that their suggestion could create more problems than they actually solved.

In my book I have maintained my long-held stance that eBook compatibility is one of the highest priorities. The goal is to create eBooks that look good on any reader out there, whether it is a tiny cell phone or a large desktop computer. I am a professional eBook formatter (Click here for more information if you are interested in my services) and I have prepared more than 700 books for release in the market, by an enormously wide range of authors and styles. Of these 700 books not a single one has been known to cause formatting problems, clearly showing that with insight and forethought, it is possible to create eBooks that are compatible even in a market as fragmented as eBooks.

I am sure it won’t surprise you that many of the techniques outlined in my book will cover the subject of eBook formatting from that angle, offering up safe solutions, or, where no safe solutions are available, at least pointing out the risks and challenges and how they can be minimized by the formatter.

Filled with tips, tricks, techniques, examples, screenshots and plenty of code, the book will hopefully become a one-stop solution for all authors who want to dive in to the technical side of their eBook projects.


Would you like to use my services?

Need help with an eBook project? Check here for more information.

Do you need a cover for your book? Check here for more information.

In need of an author website or blog? Email me at for more information.

We are heading into year six of the digital book revolution and while there have been tremendous advancements in the sector, one thing has not changed a bit. There still is no magic bullet for eBook formatting. It’s not even anywhere on the horizon.

Dragonlance1In a time where eBook readers have become increasingly powerful and capable, and where more authors than ever put their content out in the market, one would think that formatting manuscripts to publish them as eBooks should be as trivial as exporting them from a word processor, but alas, that is not the case. Whether it’s releases from small indie authors or titles from major publishers, I continued to stumble across eBooks that are shoddy at best. Just a few months ago I was re-reading the Dragonlance Chronicles by Hickman/Weiss—a staple of high fantasy literature that has been in print for 30 years now, and yet, the eBook versions are an abomination in many ways. While it is evident that some work went into the books, they are nonetheless riddled with formatting errors that clearly show that no one at Wizards of the Coast took a single look at the books once they were formatted, let away read them before they went out the virtual door.

Is that truly the promise of the digital age? That we have to content ourselves with mediocre quality and sloppy presentations? It is just because it’s easy and cheap to produce and anyone with a computer can do it? Or is it because price points have come down so much, resulting in content creators and publishers no longer caring about the products the way they used to, because it’s all considered shovelware, anyway?

I’ve said it many times, but it is well worth repeating. The formatting of your eBook is every bit as important as your cover and your story. If your book becomes unreadable because line breaks are mutilated, margins jump all over the place, fonts get butchered, graphics become indistinguishable or errant page breaks destroy the flow, you are in trouble. I have put aside more than a handful of books after a few chapters because I found the reading experience too egregious — and I am sure that I am not the only one. (I remember vividly, the first one this ever happened to me was Charlie Courtland’s “Dandelions in the Garden,” for which I paid $9.99 on the Kindle and had to put down after two chapters because every single page was riddled with a multitude of typos, grammatical errors and formatting flaws-all of which the author herself considered a matter of personal taste and absolutely acceptable.)

Sure, the temptation is enormous as a writer. You have finally completed your book after a year’s worth of writing and—hopefully—tweaking, and without a publisher to hold you back for another year, you are eager to put your work out in the market, in the hands of readers. Nothing wrong with that. The problem really starts when you believe that the “Export as ePub” function in your word processor is your road to an instant release.

Kitt PirateWord processors are a great piece of software, but they are designed to write text and to do a bit of layout work, perhaps. All of it with your computer screen or a printed page in mind. Absolutely nothing in a word processor is designed for the requirements of eBooks. The famed “Export as ePub” function was nothing but an afterthought in that software, that has been included because someone thought it may help sell a few extra copies of the word processor or entice the growing army of aspiring digital authors to finally upgrade their software package.
eBooks have very specific requirements, capabilities and limitations, and they are not adequately represented by word processors. Things that look right on the screen or the printed page may not work the same way on an eBook reader.

While it is possible to create a good eBook with a word processor, it requires intimate familiarity with the software’s features. If, for example, you do not know what the difference between a soft and a hard line break is, let away how to create each, or if you do not know how to properly space text and paragraphs, the odds are, you won’t be able to create a solid eBook output. If you’re not familiar with your word processor’s style functions and are not religiously and obsessively using them, or if you do not know how to properly create an automatic bulleted list in your word processor, chances are that you are not ready to export your manuscript as an eBook using the “Export as ePub” feature. The list goes on like this.

I am not here to make you feel bad, because considering how complex word processors are these days, few of us truly master the software. But that’s not the point. You don’t have to, if you’re a writer. Your job is to write a cool story, pack it all up nicely in a suspenseful and engaging way that keeps readers glued to your words. Making sure it fits the technical limitations of an eBook reader is someone else’s job. Or rather, it should be. Someone with an understanding of the technical side of things, and with the ability to whip your writing into such shape that it works on any device. It’s a specialized field of expertise where the experience you purchase will save you countless hours of headache and will protect you from having to deal with potentially countless upset readers and customers.

It may be fulfilling to see your complex layout with text flowing around images and wonderfully elaborate drop cap initials on your iPad after exporting it as an ePub file from your word processor, but have you ever wondered, what the book may look like on another device? An early-generation Kindle, a Nook, perhaps, or the Kobo reader? What about a tiny cell phone or a retina computer retina display? Not all devices that people read your books on are equal. There are huge gaps in capabilities between various devices, and your software exporter cannot—and will not—accommodate them. It won’t even try. It will try to create what the programmer who wrote it deemed best, even if it means that in the real world you are leaving 90% of the market by the roadside.

Even within device families there are enormous capability differences. The Kindles, for example, by far the most popular eBook readers, range from a device that is barely capable of displaying an image (Kindle 1) to a full-blown tablet that can do virtually anything, including play games. Most Kindle devices have serious glitches and firmware bugs that got progressively worse with each generation. I made a blog post about the subject three years ago and it is frightening to see that Amazon never addressed as single one of these “10 Things Amazon should correct in the Kindle”. So, when you format an eBook, you definitely need to be mindful of these differences and idiosyncrasies at all times.

But back to even the general capabilities. Amazon for all the great stuff they’ve been doing for the eBook revolution, has completely dropped the ball on various fronts over the past years, clearly indicating that the company simply looks forward without ever trying to patch up previous mistakes. As a result there is no easy way to bridge these different capabilities in any workable way.

Ideally you would want the ability to create dedicated eBooks for devices with different capabilities, but sadly Amazon and every other distribution outlet does not allow for that. You have to have one build of your book that serves all devices. While Amazon allows a bit of conditional formatting, it is in reality very basic stuff that is so rudimental that it is mostly useless. Therefore you are forced to build your eBooks for a common denominator and you have to make sure it will work on all the devices out there.

No “Export to ePub” feature does that, which brings us back to the point that you should work with people who specialize on that kind of thing. As you may know, I have written an extensive eBook formatting tutorial some time ago, and I am offering eBook and print formatting as services. The truly amazing thing about the tutorial is that over time it has become the de facto standard for the industry and that that even now, four years after I wrote it, it is still valid and applicable in every single aspect. In a world where technology moves at such a rapid pace, it is clearly a testimony to the quality of the underlying fundamentals of the tutorial. Every book formatted following the tutorial still works on every device out there, and it is still the same general process I apply when formatting my clients’ eBooks.

On the IslandIf you would rather focus on your writing and leave the technical aspects of your ebooks to people like me, feel free to send me an email. I have formatted over 700 books, all of which are available in eBook stores worldwide, and many of them are full blown bestsellers selling hundreds of thousands of copies. And among these roughly 700 books, not a single one has caused any problems in the past!

If you want to make sure your readers are happy with the eBook you sold them, and if you want to make sure the books won’t be returned because of weird glitches or formatting errors, feel free to take a look at this page where I am outlining my services and my fees. I am happy to work with all sorts of authors and publishers, big and small, to make sure they can publish their books with confidence.

Forget about the promises of a magic bullet. It does not exist. Instead, take the proper steps to ensure the quality of your eBook from the inside out.

For more information and professional tips and tricks, please make sure to also check out my new book Zen of eBook Formatting, which is now available on Amazon.

The announcement of the next generation of Amazon’s Kindle has set the eBook world abuzz once again. Not only are the new models more attractive than their predecessors, but they also expand the market in new, untapped territories. For authors, this is great news, of course, but often, where there’s light there’s also darkness.

Kindle PaperwhiteIn this case, the cloud on the horizon lies in the technical specs of these new devices. With a bit of worry I have observed over the past year or two that the eBook market is becoming more and more fragmented. In a very bad way, it reminds me of the mobile game space I have also been working in, where, at times, it was necessary for us to build up to 200 different versions of the same app to make sure it properly supports all the handsets in the market.

While the eBook market is not nearly as bad, of course, there is an increasing trend of changes – or call them features and improvements – that can work like sand in a ball bearing.

Fortunately we have to contend with only two generic eBook formats at this time – MOBI/KF8 and EPUB – and it is easy enough to build eBooks for both formats from the same sources.

However, since the inception of the iPad, problems have cropped up that force eBook publishers and formatters to think very hard about what it is they want to do and how to achieve the desired effect. Fixed-layout books and their particular quirks, and the lack of a general standard to create them, is just one of the issues publishers have to tackle these days, and it is exacerbated by the fact that even within the Kindle line of products, it is not possible to really create specialized builds for each platform. A fixed-format Kindle Fire eBook will inevitably make its way onto a regular Kindle – where it doesn’t belong – because Amazon does not give publishers the possibility to create specialized builds. As a result Kindle owners will look at a book that is horribly mangled and probably unreadable, while it looks mesmerizing on a Kindle Fire. I am not sure in whose best interest that is, but that’s the way Amazon does it.

The reason I am writing about this is because according to Amazon, the new Kindle Paperwhite line of models offers 65% more pixels. In plain English, it means it has a higher resolution than previous Kindles. That is really great news in regards to sharpness of the text, of course, but from a formatting standpoint it causes certain problems. An image that was perfectly sized for the Kindle’s 600-pixel resolution to date, will suddenly appear much, much smaller on the page. In many instances, this will not be overly dramatic, but if you use images deliberately as a design element, it will force you to rethink how you approach images in eBooks. Just image how tiny the image will look like when it’s being displayed on the new Kindle Fire HD with a resolution that is three times as wide as that of the original Kindle.


How would you like your artful chapter heading to look like?

In the past I have sized images to suit the 600 pixel screen. It helped keep the file size in bay – why bulk up a book’s footprint for no apparent reason, especially since the publisher is being charged for the delivery of the book based on the size of the file. This approach may no longer work, however, if you want high quality images across the board.

I’ve been therefore rethinking my strategy and going forward I am sizing images to a higher resolution and then determine their on-screen size, using scaling through my CSS style sheet. This allows me to make sure the image will always appear the same on the display, without degrading it on higher resolution screens. If anything, it may degrade the quality scaling images down to the older Kindle models.

If Amazon offered platform specific builds for their line of Kindles, this would not be a problem, but things being what they are, a one-size-fits-all approach is necessary, and hopefully, this will do the job.

In many ways, I wish that Amazon would make me part of their Kindle design team or at least would allow me to work with them. After all, I’ve had over 35 years of experience as a software engineer in arenas that were a whole lot more complex than an eBook reader.

Many of you may remember my post 10 Things Amazon should correct in the Kindle from a year ago, and it is rather disheartening to see that virtually none of these issues have been addressed. In fact, if you look closely, not a single one of the issues has been addressed to date. While I have not seen a Kindle Paperwhite at this time, I doubt there will be many changes in the firmware that would address these issues. It seems to be more of a change in terms of the form factor and a hardware upgrade than a rework of the actual reader implementation – but I could be wrong, of course.

To me as a software engineer, author, publisher and professional eBook formatter, the omissions are truly painful to behold. amazon has done great things for books, by truly establishing eBooks as a reading medium, making it the new mainstream standard, all the while opening the doors for authors to publish their own work. All great achievements and I honestly doff my hat to Amazon for their incredible foresight and the vision they had during the past three years.

That, however, makes the technical shortsightedness all the more prevalent. All of the issues I raised before have been around since day one, and clearly someone within Amazon should have championed their correction. It did not happen. Not even when people like myself and others have called them out.

Amazon has never been a software or hardware developer before the Kindle and as such it was to be expected that there would be hiccups in the product and the delivery. No big deal. However, the market has reached such a maturity, that glitches like inconsistent text justification, the lack of transparency in PNG images and other omissions become glaring issues that should have been resolved two years ago.

The Kindle has to mature and it has to mature with foresight or we are gong down the road of mobile games, where you need 200 individual builds of an app. There are great developers out there who would have been happy to assist Amazon in their objective, but instead of embracing them, Amazon has often shunted them.

A command-line MOBIGEN program is just not the same as the luxury you get out of a program like Calibre. Amazon should have long looked into creating high quality content creation tools that help authors to increase the quality of their output. Too many self-published books are still created with an MS Word export or an InDesign plug-in that cause more problems than they solve.

Amazon should also have long started to put in place platform-specific delivery of eBooks, along with was for authors to properly set up books for each of these platforms.

Amazon should also have expanded their eBook format in ways that are truly practical without having to jump through hoops. The introduction of KF8 was a horrid debacle to say the least. Confusing authors and readers alike, the implementation is not what it should be – many things could have been implemented much more efficiently, making it easier for formatters to prepare the eBooks while also giving them a certain level of control over the appearance of their content. If you’ve ever tried to take a look at a black and white line-art image in the “Night” setting of your Kindle, you know what I mean, and the whole image sizing issue puts the dot on the i, I think.

I don’t want to harp on this unnecessarily excessively, but it also appears as if Amazon has long forgotten its pledge to bring KF8 support to the Kindle 3 generation of devices. As far as I can tell, that has never happened either, and yet, the train of model innovation moves on…

With all the new glitz and glamour that accompanies every new Kindle model, for publishers, each new generation brings with it a new set of challenges. It’s not necessarily a bad thing, but as I said, I wish Amazon would allow me to work with them to help them make these transitions as easy as possible, at least from a content creation standpoint. If anyone from Amazon is reading this, you know where to find me…

I’ve been working my way through Amazon’s new KF8 format specs a little bit, and while it is a great format, taking the Kindle eBook format to where EPUB has been for some time, I have to say there are a few things that stick out like a sore thumb.

One of the issues that truly and really disturb me is the lack of support on anything but the Kindle Fire. Although Amazon had initially announced that the current generation Kindles and software readers would be KF8 capable, that statement was simply not true. It has since been revised that these devices will support KF8 some time in the future. In the real world that is a big difference.

It means that if you’re using KF8, you are currently limiting yourself to the Kindle Fire platform. While it is clearly a successful platform, it is nonetheless a niche.

The other thing that sorely disturbed me is the fact that Amazon is in no real way accommodating MOBI alongside KF8. By this I mean that Amazon is not willing to allow you to upload a KF8 version of a book and a MOBI version of the same book in order to enable proper support for all their Kindles. This problem extends not only into the publishing platform but actually starts at the root, the authoring of eBook.

Although with the new tools, Amazon has set up media queries, using an HTML @-rule, which allows you to define different styles for the KF8 and MOBI builds generated from your submission file, it is sadly a rather mediocre solution. It does help, however, in some cases. If you want text to flow around an image, a feature the KF8 format finally supports, you can tell it to use a different style setting for the MOBI version, in which you could center the image and then force a line-break and start the text on the next line. In theory, this would work. The problem seems to be that the old Kindles do not understand the display: block property that would be necessary to enforce the line break. Unless I find some way to tell the old Kindle that it needs to perform a line break after an image, this media-query fix is useless in this case.

The same is true with tables. Old Kindles have no table support. It’s been a major problem in the past, as it makes tabulating information impossible. If you display a KF8 table on an old Kindle it will be flattened, which means every table column will appear in a separate line. From a technical standpoint it makes sense because it is the easiest way to parse a table without actually implementing support. In practice it defeats its purpose, because it completely mangles and intermingles data that should, by rights, be separated — hence the use of a table.

Sadly the newfangled media queries won’t help in this case either, because the only real substitutes for tables on old Kindles are either completely restructured data, which requires different structural code and cannot be managed using a style, or you could replace the table with an image, which also requires code and cannot be achieved via a style setting. Ergo, the media query once again misses the mark.

Nonetheless, the media queries are great and will help on occasion to allow a certain degree of “correction” between versions. At least it’s a try…

In my opinion, however, Amazon should allow publishers to upload separate KF8 and MOBI versions in the future. It would be the only way to make sure that both versions can be authored to the best of the respective format’s capabilities and look as best as they can. Trying to automate the process – even with a media query hint has never been a good idea. The Smashwords Meat Grinder is the living proof that this Least Common Denominator approach is getting you nowhere but in trouble, and therefore I sincerely hope that Amazon will rethink their strategy in that respect, and while they’re at it, maybe they should look at their documentation also and rework the CSS selector listing they have in there, because as it stand, it would lead you to believe that old Kindles can’t handle any CSS, as every single selector is marked off as “unsupported.”

I wonder if they have actually corrected some of the issues I raised a while ago in the new platforms, such as incorrect em calculation, the right margin and padding issues, the missing borders, and so forth. Maybe some of you reader can enlighten me on that, since I have no Kindle Fire and none of the latest Kindles at my disposal.

Yesterday, Amazon released information that with the introduction of the Kindle Fire tablet they will also switch to a new eBook format. Anyone who will check out the quick overview will certainly be pleased and also notice that with the upcoming KF8 eBook format, Amazon seems to have addressed virtually all the shortcomings I have raised in my blog post 10 Things Amazon should correct in the Kindle that I posted a while ago.

And yet, I am not happy. Why is that?

One would think with these issues out of the way, the Kindle should finally catapult itself to the top of the eBook capabilities, right? Well, yes and no. The problem lies in the details, the fineprint, so to speak. The big problem with the introduction of the KF8 format is that Amazon is doing a pretty hack job with this, I am very sorry to say, because, according to Amazon’s announcement and FAQ, none of the older Kindles will be able to support this format.

Why is this a problem? Well, as a professional eBook formatter, the question for me is, how am I supposed to deal with this? Instead of creating the foundation for one rock solid Kindle platform that has powerful capabilities, Amazon is now going down the road of platform fragmentation. Already we had issues that the Kindle 2 and Kindle 3 had capabilities the Kindle 1 did not possess. It was a big problem because things such as tables were unusable, despite the fact that the capabilities were built into the K2 and K3. Since authors have to make sure they cover the largest possible market share, however, using tables made no sense, as the Kindle 1 did not support them and rendered them in a useless, garbled fashion.

With KF8, things will get even uglier. We now have three different sets of capabilities. The Kindle 1 at the bottom end, the Kindle 2 and Kindle 3, and then the new Kindle 4 and Kindle Fire. This is not a smart move on Amazon’s behalf and reeks of either laziness or engineering ineptitude.

From a programming standpoint none of the features introduced in KF8 are in any way supercharged capabilities that require special hardware. Let’s face it. eBook reader software is, in effect, nothing more than a specialized web browser. It is not rocket science! Therefore, Amazon’s decision is hard to comprehend. Web browser implementations have been written a thousand times — I wrote one myself 10 years ago for use in a computer game. There are reference implementations out there that they could have used for free, all things that should have made it possible to retain a unified platform. So, why could’t the software engineers at Amazon make sure they introduce these capabilities in all devices through firmware upgrades?

It is a very short-sighted decision in my opinion, that not only shortchanges the end users, but causes a lot of problems on Amazon’s end as well.

They will now have to begin offering and delivering different versions of the same books – one formatted according to the old, outdated MOBI file specifications, and another one formatted according to the new KF8 guidelines for this to make any sense. How does that make sense?

So, not only will they now have to deal with publishers having to create and upload multiple versions of the same book. This comes at an additional expenses to authors and publishers, as they have maintain two versions of the book. But it also comes at the expense of Amazon, as they have to modify their existing pipeline to accommodate these multiple versions.

To make matters worse, they will have to educate people which format to use for which device, and they will have to prepare – and possibly ramp up support staff, to answer all the customer questions stemming from this sort of confusion.

As I said, I do not think this was a very smart move and it is not in Amazon’s best interest.

Writing and updating the firmware for all existing Kindle platforms would have been a clean way into the future, without all the hassle that comes with platform fragmentation. I know what I am talking about – I’ve been programming for 30 years and I’ve been working in the mobile field for many years, where device fragmentation has gone rampant and costs publishers and cell phone carriers hundreds of millions of dollars every month just to support the insanity.

I know, that for me, KF8 is a step backwards, no matter how attractive it looks at first glance. For the most part it is useless out of the gate because if it doesn’t work on all Kindle devices, it has no value to me and I suspect most of my clients.


Addendum:

An important point was raised in the comments to this post that deserves a few additional words, I think.

Amazon promises that KindleGen 2, the tool they provide to allow authoring KF8 files “will convert your content so that it works on all Kindle devices and apps.”

If you think, this means that all problems are solved with this, you can smoke that notion in a pipe. There is a big difference between could and should.

Just because KindleGen 2 promises to convert your books, doesn’t mean you should, because the output quality will be dubious at best. Of course, if you are part of the I-don’t-care-just-make-it-easy, Smashwords-adoring crowd, yes, that might work for you, but if you take pride in your ebook’s layout and formatting, this is not going to fly.

Let me illustrate this with a very simple example. Say, you have an image and you add the float property to it, to have it embedded in your text with the words flowing nicely around it.

When converting such a file, all KindleGen can really do is ignore the float property — which, coincidentally, all the devices do already. As result, on a Kindle 2 you will now have the image sitting on the left side of the screen with nothing surrounding it. Perhaps the first line of the text that was supposed to float around it will sit firmly at the bottom, creating a huge, ugly gap. Surely not what you had in mind.

If you had properly formatted a version for MOBI devices, instead, you would perhaps have centered the image in this case and spaced it out a little more. That is where KindleGen’s auto-conversion will fail you miserably, because it cannot make decisions like that for you. Things will, undoubtedly get even nastier when your formatting is more complex than this one very basic example, and I would not be surprised if certain elements would even disappear entirely.

Let’s face it, there are certain things the old devices simply can’t do if Amazon refuses to upgrade their firmware across the entire line of products. Just having some devices that support it and others that don’t is hackneyed at best.

As a publisher you will have to look at the lowest common denominator for your product, and that is the long-abandoned Kindle 1, that has seen little love from Amazon in recent years.

Sure, this is not a big problem if you have a novel without graphics or a special page layout. Fair enough, in that case you are really not affected by these changes at all. You will continue to build MOBI files exactly the way you did and ignore the new capabilities, because MOBI offers exactly the kind of functionality you need. Nothing wrong with that.

When books become a little more complex, that is when the problems begin and they will very quickly become exacerbated.

The bottom line — and the main point of my post — is that the way Amazon is approaching this is creating tiers of devices, each tier with different implementational limitations. And that, my friends, is a very real problem.

I am a huge fan of the Kindle. Always been. I owned a first-generation Kindle and in my mind, the Kindle was every bit as revolutionary a product as the iPhone. A game changer.

However, as great as it is, even the Kindle is not perfect. I am not talking here about buttons being too small or somesuch thing. I am talking about the software implementation in the device.

Over the past two years I have formatted hundreds of e-books, as I’m sure you know. I have formatted books for NYT best-selling authors, for publishing houses, midlist authors and indies alike, and I have been able to study many of the idiosyncrasies of the ebook readers in the market close up.

The Kindle has a number of firmware bugs that have unfortunately not been corrected in its three-year lifespan or its three platform generations. At first I was always willing to admit that it was easy to forget that Amazon is simply not a software company but a retailer. So the experience pool is simply not there and mistakes happen.

As the competition mounts we can no longer be so forgiving, I suppose. Apple shows everyone how it is done with an ePub implementation on their iBooks platforms that not only lives up to spec for the most part, but extends it with significant improvements. Apple may drop the ball entirely on the store side of iBooks, but that’s a different story for another blog post.

I think, however, that Amazon can no longer afford to let things like these firmware bugs slide and should take steps to address them properly. Not only in the current or upcoming platform generations, but backwards also, to make sure all Kindle users enjoy the proper, highest quality e-book experience they are looking for.

Here is my list of 10 Things that Amazon should correct in the Kindle.

  1. Let’s start with a simple one. Image transparency. The Kindle supports PNG images but not the format’s transparency settings. Instead it renders the background white. This would be a simple software fix to correct the issue and could be done in a few minutes. In fact, it is surprising that this bug exists at all because PNG transparency is one of the image format’s most basic features.

    Transparency error
    Notice how the background of the image is white against the sepia paper color, while it should be transparent.
    Click on the image for a larger view
  2. Em-spacing. As a book formatter em-spacing is the key to all good formatting, because it allows for proportional scaling of the content, which is key for applications in which text is free flowing – such as e-books. Currently the Kindle miscalculates the size of em entirely, making it about 4 times larger than it should be. Proper formatting using em-spacing is therefore problematic on the Kindle and I am sure everyone agrees that spacing in pixels is unacceptable in a world where display sizes range from the tiniest cell phone to the largest tables and desktop screens.
  3. Margins are also a sore topic on the Kindle. Not only are margins calculated incorrectly as a result of the em-spacing error mentioned above, the Kindle completely ignores all margin-right settings. To make matters worse it ignores all padding-right information also. As a result it is impossible to space text properly in various occasions.
  4. Border properties are also ignored in many cases. Depending on your Kindle generation or software you may or may not see borders that have been created using the border style attributes in the e-book.
  5. One of the biggest issues, perhaps, is text justification. The Kindle does not properly justify text. Every few lines or so it will suddenly create a ragged line, throwing off the formatting. This is clearly a software bug that should have been addressed long ago but for some reason it hasn’t been addressed even though it is at the heart of the most basic function of the Kindle, the actual flow of text paragraphs.

    Justification error
    Notice how the lines in the top paragraph are ragged when, in fact, they should be fully justified.
    Click on the image for a larger view

  6. Going along with this issue is the lack of hyphenation. While the Kindle software reader software support hyphenation, the Kindle devices do not. Now, I can understand that perhaps the dictionaries necessary to do proper hyphenation may be too large to fit on a Kindle or may be too processing intensive – though I honestly doubt it, giving modern software technologies – the fact that the Kindle does not even support HTML’s soft-hyphenation is really a disappointment. Hyphenation is integral part of text flowing and I am not sure why it has been so overlooked for all this time.
  7. Early generations of the Kindle also do not support tables. When at first the Kindle arrived and was used for novels mostly, this was perfectly fine, but as the acceptance of e-book readers grows, so does the diversity of the books, and, let’s face it, text and reference books need tables. There is always a need to be able to tabulate content, something the Kindle makes impossible. While the current Kindle generation supports tables, it is a feature that cannot be used because legacy readers do not. This feature should be introduced to the Kindle 1 retroactively with a firmware upgrade also to ensure uniformity across all generations.
  8. Another point of contention is object floating. The float property is not part of the mobi e-book specifications, but let’s face it, these specs are older than your last computer. Amazon has bought the company that developed the mobi e-book file format but sadly the development and extension of the format has completely seized, making the Kindle the only e-book reader with a completely outdated e-book format. Before you tell me that Amazon also allows ePub submissions at this point, let me remind you that Amazon converts these ePub files into mobi files before delivering them to users, stripping the e-books of all ePub specific features. The float properties would allow text to float around images, giving us not only the opportunity to insert images into the text, but they would also make graphical drop caps a possibility at last.
  9. What is also missing from the Kindle is a way to properly deep link to other books in the Kindle store. Sure you can use a link to Amazon’s website and insert it into your e-books, but did you ever look what happens? The Kindle tries to display the Amazon website on its screen, rendering it garbled and virtually unreadable. Why not give Kindle authors the chance to link to page that has been optimized for the Kindle like the one the Kindle pulls up when you search and purchase a book directly on the device. I cannot tell you how many emails I have exchanged with Amazon on this subject but for some reason the support staff does neither seem to understand the issue, nor care much about it. I was continually referred to use either regular Amazon web links or some XML links that the Kindle could not even interpret properly. Since upselling more books would be in Amazon’s interest every bit as much as in the authors’, I am flabbergasted at Amazon’s disinterest in providing such a specialized deep link.

    Store page
    This is what a deep link to the Amazon store looks like on the device. Not very useful, is it? Most of it is not at all readable.
    Click on the image for a larger view
  10. Last, but not least, Amazon should spend some time to make sure the software versions of their readers are actually representative of the devices. They do have the best software readers out there — don’t get me started on the Nook software reader that can’t even center text and will crash in 9 out of 10 times — but the way a book looks in the reader is not representative of the device at all? Why is that? Just use the same fonts, the same firmware routines and things should look identical. It is called code portability and I’ve done it for 10 years on cell phone games, making games look the same on hundreds of different phones.

As you can see, these are some basic flaws and it is surprising that they have been sliding by for so long. The things in question are not tied to hardware issues at all. They are all simple software bugs that can be addressed without too much of a hassle. It is really not rocket science. All it requires is a little discipline.

If you agree with me, maybe you would join me in telling Amazon about these issues and reminding them that in order to remain the market leader, they will have to make sure they continue to deliver a superior experience.

Send them an email at kdp-support@amazon.com. Send them a link to this bog post or pick your favorite flaw and ask if they could please fix it. Maybe together we can direct Amazon’s attention towards these software errors that truly deserve to be fixed.

Oftentimes when I send out a finished e-book to a client after I completed the formatting for them, I get an email that asks me, “Why is the Table of Contents in the back?”

The more I thought about it, the more I felt it is something I should probably talk about here on my blog, because there are a number of reasons why placing the Table of Contents — or TOC — at the end of an e-book makes a lot of sense.

Traditionally, in print books that is, the TOC served for readers to orient themselves within a book. You would simply crack the book open, go to the TOC, look for the chapter of interest and then go from there until you got to the chapter you were looking for. We all know where to find a TOC in a print book — in the front — and through years of practice we have learned to use our eye to estimate a position of a certain page number within the whole of a book.

In an e-book things look a little different, however, because if the TOC is in the front, and you are currently reading on page 560, you will have to do a lot of paging to do in order to get to that Table of Contents. Hundreds of button presses are in order… That doesn’t sound cool, does it? No, instead e-book readers have a button that takes you to the TOC, so that a simple button press takes you to a menu from which you have direct access to the table of contents. From anywhere in the book. And you won’t even lose your current reading position.

Hold on a minute, doesn’t that mean…? Yes, it does. The word menu means that the TOC does no longer have to be in the front of the book, because no matter where it is, the e-book reader always finds it for us and displays it in its Contents menu. In fact, it does not have to be part of the actual book text itself at all anymore.

Yeah, but you’re traditional-minded, right? Like, you never thought you’d be using a digital thingie-ma-whatsit to read books on anyway, because you like the feel of a bound book. And because you are a traditionalist, you want your TOC in the front nonetheless, just for tradition’s sake.

Well, not only have you obviously made the switch to digital despite your traditional preference of the printed book, but take it from me, you also want to adapt to modern TOC usage. There is a very good reason why you would not want your TOC in the front of the book.

Apart from the fact that it can potentially give away major plot points through chapter titles, which would be the first thing people see when they open your e-book, the main reason is a thing called reading samples. How does that make sense? Well, think of it this way. When Amazon creates an excerpt of the first 20% of your book to allow people to sample it for free, they take it from where in the book? The front, that’s where.

So, instead of using that exceedingly valuable space to hook your potential future readers and clue them into the premise, your style and the story of your masterpiece, you are boring them to death with a Table of Contents that contains — at its worst — nothing but a three-page list of the numbers 1 to 85. Perhaps you also threw in about five pages of legalese and credits and acknowledgments and such.

Honestly? I don’t think that’s a particularly good way to win over potential readers, let away convince them to give you their hard-earned money for the effort. Therefore, it makes sense to put non-essential things, such as a Table of Contents, in the back of the book where people can reach it but are not forced to sit through it and most importantly, where they are not bored by it when they first open your e-book or reading sample. First impressions are vital — never forget that.

This is no longer the world of print books. Things have evolved and the Table of Contents has evolved with it. Not only has its placement in the book become irrelevant, it has become interactive and therefore deserves special treatment in every possible way.

As people tackle the subject of e-book formatting, every once in a while I receive an email with the question, what meta-data in an e-book are actually used for. Since you will have to re-upload your book description, the ISBN and the keyword tags on every distribution channel’s portal again and again, the question clearly becomes, why am I entering it in Calibre in the first place, if it isn’t being put to use?

First, let me say that it is possible to create e-books without most of the meta-data. Things such as the product description, keywords, ISBN identifier, publisher and so forth are not mandatory, so if you feel lazy, you can leave them out.

However… you knew there would be some kind of catch didn’t you? So, however, if you think they are not being used, you are mistaken. Meta-data are being put to use in a number of places, but the most important one for you as a reader is probably the device itself.

Meta Data Example

When you load your book onto your Kindle or Nook, you see a listing of titles in your library. Depending on your settings and your device, you will also see a small thumbnail of the book’s cover. Do you have any inkling, where that comes from? The meta-data you provided, naturally.

But that’s not all. Many devices allow you to sort books by author, again, using the e-books’ meta-data to dictate the sorting. If the library software on your device is a bit more sophisticated it will allow you to categorize books by genres and keywords, using the “keyword” meta-data you have provided in your e-book.

And so it goes, on and on. While I can’t think of any platform that currently makes use of it, it is also easily possible to think of software that allows you to take a quick preview of the book by printing the product description — culled from the book’s meta-data, of course.

It may feel like you are duplicating information over and over again as you prepare your e-books and upload them to distribution portals, and in fact, you are. I, for example, would love for Amazon to retrieve the necessary data from my e-book file by default, for example, saving me the time it takes to enter all that duplicate stuff, but ultimately it is of no relevance. The process is easy and fast enough as it is, so I have no real complaints here.

What is important, though, is to understand that a book’s meta-data are being put to use over and over again, silently, in the background, to make sure your readers will get the most out of the book and their e-book readers. In fact, I would not be surprised to see meta-data expanded upon in the future to include proper library categorization, author biography and cross references to other books by the same author or titles in a series. These additions may just be around the corner, as Apple is already requesting that sort of information when you upload your book to the iBookstore. Hilariously, though, it makes absolutely no use of the information at this time, it seems, as the iBookstore search engine is about as dumb as a piece of bread. But hey, you can’t have everything…

So, is it a good idea to skimp on your meta-data? Probably not, even though it may seem like redundant information.
http://guidohenkel.com/category/formatting/
guidohenkel.com
crawl=CC-MAIN-2014-23
102917
application/http; msgtype=response
sha1:MRXSTWOOMYLOFWZDYQVYN2YHKUAL77AI
<urn:uuid:9a292501-3901-4fe6-a294-c4cafb33f2bb>
2014-07-30T00:54:32Z
64.182.224.102
sha1:LIZJURYWY7IBZHOL5XRGVZ27CM3OED5H
<urn:uuid:69c3fd2e-c9a6-4fa6-bc5a-77f840a2f502>
http://guidohenkel.com/category/formatting/
length
response
<urn:uuid:cbba04d1-7370-43f0-84d6-c130673bf14e>
robots: classic
hostname: ip-10-146-231-18.ec2.internal
software: Nutch 1.6 (CC)/CC WarcExport 1.0
isPartOf: CC-MAIN-2014-23
operator: CommonCrawl Admin
description: Wide crawl of the web with URLs provided by Blekko for July 2014
publisher: CommonCrawl
format: WARC File Format 1.0
conformsTo: http://bibnum.bnf.fr/WARC/WARC_ISO_28500_version1_latestdraft.pdf