Whether it’s for Kindle or ePub—why you should never use an exporter for your eBook formatting

In recent days I’ve been visiting a number of message boards related to the indie author community. It is something I had not done in a long time. In over a year or two, in fact. The other day, however, I decided to take a look at some of the forums I used to frequent and realized that the amount of misinformation spread on these message boards is simply horrifying. Particularly when it comes to eBook formatting.

The reason for that is not so much that people are malicious, but that they are oblivious to the many problems inherent in the eBook formatting field that they think what seemed to have worked for them is a universal formula that will work for everyone.

ZenCoverThe problem is that they are sadly mistaken because their own efforts were severely flawed – they just never realized it. Whenever someone recommends to export a manuscript from a word processor or Scrivener, you are seeing one of the biggest mistakes perpetuating. If eBooks are to grow and mature, authors have to realize that formatting eBooks is not a one-click affair. Probably never will be. It takes effort, expertise and a certain know how.

But it works for me, you may say. As I mentioned. It doesn’t. You only think it does, but with five or more generations of eBook devices in the market by now, each with different limitations, quirks and firmware bugs, no word processor exporter will be able to produce an eBook that works reliable on all these platforms.

For that reason I have decided to publish here an excerpt from my book Zen of eBook Formatting, which explains in more detail why you should never ever ever ever use an exporter to build your eBook. For much more information and techniques that will help you create professional-grade eBooks, please make sure to take a closer look at the book. But please, read on…


The Road to Right

Understanding eBook readers

Before we dive headlong into the technical aspects of the creation of eBooks, I believe it is important to understand eReaders a bit better, and how these devices have shaped and changed the way we are experiencing books.

eBook readers have originally been designed with novels in mind. Nothing else. The idea was to make it possible to read novels in digital form, and when you look at novels you will quickly realize that there isn’t a whole lot to them from a presentational standpoint. They have a cover, some front matter and then it’s just reams and reams of text, interrupted only by the occasional page break to mark the beginning of a new chapter. With that in mind it is hardly surprising that eBook readers originally did not have a lot more functionality beyond that. Even today, many eBook readers do not go a whole lot further than this, which creates a very unique set of challenges when you format eBooks. This becomes particularly evident when you leave the novel segment behind and begin to look at non-fiction books where these limitations often become very obvious very quickly.

One of the biggest challenges we oftentimes face as we prepare eBooks has to do with the fact that we cannot know which device or software our customers will use to read the book. It could be a Kindle or Nook with a black and white eInk screen, but it could just as well be a cell phone with a tiny display, a tablet with a nice high definition color screen or a desktop computer with a humungous widescreen monitor attached to it. We have no way of knowing, and we have no way of identifying these different devices, all of which have very different capabilities and create very different reading experiences. A page layout that works on a large screen may suddenly become unreadable and garbled on a small screen, especially because navigation of eBooks is oftentimes very limited and cumbersome.

Another limitation that I have to explain very frequently is that eBook readers do not support a whole lot of different fonts. While some eReaders may offer a variety of different typefaces, the problem is that they are not standardized and are oftentimes not available on other devices. Therefore, using these fonts will dramatically alter the way your book will look and flow on a different device. To make matters worse, custom fonts are not universally supported by eReaders, making it impossible to, perhaps, use that one font you have always loved so much and used in your print layout of the book.

The first thing you need to understand when formatting eBooks is that they are completely different from print books. It is a different world altogether. The sooner you get away from the idea that your eBook should reflect the look and layout of your print book, the sooner you will get satisfying results. Many of the layout possibilities you have in print design, such as text inserts, text boxes, tables, the ability to have page content rotated to fill the page in a landscape format, images with text flowing around them, a multitude of custom fonts, and others, are simply not feasible in eBooks for the most part.

“Feasible” is the operative word in this context. Many of these features are available on the latest generation of eBook devices, particularly tablets like the iPad or Kindle Fire devices. The problem is that they represent only a small portion of the market, and if you want your book to sell, you cannot afford to single out a niche segment of the market like this. In fact, even if you wanted to, it is not even realistically possible, because Amazon, for example, will sell your book to any Kindle owner, not just those who own a tablet. If an eBook that has been formatted using all these newfangled fancy features suddenly ends up on a first-, second- or third-generation Kindle, the results are not only unpredictable, they are going to be abominable. And I mean abominable.

I doubt you would want to present your readers with garbled screens and have your name attached to it, and therefore it is always important to create a common denominator and build eBooks that uphold that denominator throughout the formatting process.

zen Our goal is to create eBooks that can be properly displayed on any device using any screen size!

In order to achieve such a baseline, we need to be aware of the limitations that different eBook formats and devices present, but we also have to take into consideration a variety of quirks and firmware bugs that you will find in these devices. This may sound trickier than it actually is, because in this book I will guide you, and safely steer you away from these potential pitfalls.

Why you should not use a word processor

When I visit message boards for authors on the Internet, I frequently come across the same question over and over again, followed by what is effectively the same advice over and again. Sadly, in my opinion, the recommendations are all too often ill-advised and tend to create more problems in the tail-end than they solve.

What I am referring to is the question that aspiring independent authors routinely ask once they get to the stage where they want to self-publish their books, “How do I create an eBook?” Aside from the noise that such a question inevitably generates, the tenor of responses usually goes something like “You can export an ePub file from your word processor” or “Take your word processor file and upload it to insert-your-favorite-conversion-service-here for conversion.”

To me, these responses are usually not real advice, but rather, flawed opinions. Someone suggests the procedure because it worked for them, wholly unaware that the process is richly flawed, and of the fact that their own eBooks resulting from said procedure are oftentimes riddled with problems. Not to mention that the way to get there frequently resembled a gauntlet of cumbersome obstacles and tests of patience.

Real advice, on the other hand gives you the opportunity to make an educated decision based on the evaluation of information. So, allow me to give you a real piece of advice.

zen Do not use a word processor as the source to create an eBook file from. That’s not what they are designed for.

Don’t get me wrong. I am not knocking word processors here. In fact, all of the 15 books I have written I wrote in Scrivener, including this one, but no matter what anyone will tell you, as you will see in a moment, word processors—and that includes “Scrivener”—are not very good at what eBooks do, and are therefore the wrong tools for the job when the time comes to create an eBook from your finished manuscript. It’s like deciding to hand someone a spoon and asking them to dig out a swimming pool. It is certainly possible, but at what cost?

In life, the proper tools will always make your work easier, because tools are designed for a specific task. They will perform that particular task better than any other tool, and should therefore always be your first choice. You would never use a blender to mix waffle batter, yet that is exactly what many authors are doing when they try to export eBooks straight out of a word processor.

Word processors have been designed to enable writers. They are the replacement of the typewriter—in case you still remember those. Their goal is to make it possible for people to write text as quickly, cleanly and efficiently as possible, allowing them to simply dump their thoughts onto a computerized sheet of paper and to edit it at a whim. In order to make this as easy as possible, word processing software puts a number of additional tools at the writer’s disposal, which come in very handy and are designed to help keep writers focused on the task. That is the job of word processing software.

However, as computers have become more powerful and software companies realized that they can’t keep selling the same toolset to people over and over again, they began to add features. Slowly at first, further making the writing flow more practical, it soon deteriorated into what software developers know as feature creep. It is a phenomenon that has cropped up across all branches of software development and describes the situation when features are continually being added to software without any real purpose, other than their own sake. If you take a look at today’s word processing packages you will quickly realize that they contain an overkill of flashy features designed solely to impress users. At the same time, these packages contain a smorgasbord of obscure features, many of which are actually helpful to writers but not very sexy to market. Many of them are so forgotten that most users don’t even know they exist. Or did you know that your word processor probably contains a generator to create random text? Better yet, did you know that it probably contains a feature that allows you to create “Lorem Ipsum?”

Which brings us to the next problem with word processors. Year upon year they have encroached upon what used to be known as the Desktop Publishing space. It started with simple WYSIWYG attempts, and today virtually all word processors in the market pretend to be able to do full page layout. I say “pretend” because despite thinking of themselves as being the jack of all trades, the desktop publishing features in word processors are usually completely worthless. Problems ranging from ridiculous sixteen linked-up text-box limits to erratic object handling, unpredictable text flow behavior and errors, make them pretenders in the truest sense of the word, rather than contenders.

I am rambling, I know, and I am certain you are wondering why I am telling you all this. The reason is simple. These days word processors try to do too much and obscure too much in the process with their glossy varnish—from the point of view of an eBook designer, that is.

All these fancy WYSIWYG text layout features are useless if they can’t be properly converted into eBooks and that, in fact, is the crux of the matter. Word processors are almost by definition inept in enforcing text output that needs to be formatted for variable text flow—a feature crucial to a good eBook.

To illustrate the point, let me show you the following word processor screenshot.

Screenshot 2

As you can see we have three paragraphs of text here, each formatted with a first-line indentation and extra line spacing between each paragraph. Simple enough, right? It’s what a manuscript should look like in the computer.

The problem here is in the detail, however. What you don’t see is what will run you to the edge of madness when the time comes to create an eBook, so let’s take a closer look.

The first paragraph created the indentation using a tabulation character, the one generated when you hit the TAB key on your computer keyboard, while the second paragraph achieved its indentation by inserting a series of white spaces—blanks. The third paragraph on the other hand achieved the same goal by using a style formatting, telling the word processor to automatically indent the first line in every paragraph by a certain amount without requiring any typed characters.

Three very different approaches to achieve the same thing. And notice how all of them seem to look the same in the word processor. When they are directly exported to an eBook, however, the result becomes unpredictable because all three of these approaches generate different kinds of eBook paragraphs that may or may not look the same in the end.

Make a mental note, if you will, which approach you think is the best way to handle first-line indentation. We will talk about it in a bit more detail later on in the book.

This is but a small exploration of the problems inherent in that one little screenshot. If you look at the separation of paragraphs, you are actually seeing another ugly beast rearing its head when the time comes to create an eBook. The first paragraph has been set apart from the second using an extra line feed character—inserted by pressing the Enter or Return key on the keyboard. To set apart the third from the second paragraph, however, we have once again applied style formatting instead, which tells the software to automatically insert extra line spacing of a certain height after every paragraph.

Are you seeing what I am driving at, yet? Since each of these paragraphs has been created differently, there is a very real risk that each of them will look differently once you let the word processor export your text to an eBook.

One could argue that many of these problems can be avoided by using the same way throughout the entire document, but let’s face it, in the real world, very few people are so disciplined and organized that they apply the proper style setting every time they italicize text or want to create an indentation, particularly over the period of time it usually takes to write an entire book. Since we cannot easily see existing formatting errors in the word processor, we are always teetering on the edge of hidden defects using this methodology. While turning on the display of hidden characters—a feature most word processors feature—might help in some cases, it obfuscates the actual text to the point that it becomes unreadable and you lose all sense of flow and white space. Therefore it is not of much use either, especially because to catch certain problems areas takes a very good eye. Imagine having to spot a stray TAB character in a 120,000 word novel. Yeah, right, good luck with that.

I could bore you with countless other examples where things can go horribly wrong, but since you are reading this book, I assume you already figured that out for yourself, and you are looking for a better way to do things. As authors in the real world, what we need is a way to create eBooks that produce reliable results, and word processors simply don’t do that, no matter how you turn it. What is needed, is a different approach.

zen Each device handles formatting differently and contains glitches that are beyond your control. The only way to work around these glitches is by manually addressing them in your source code. No word processor exporter can do that for you!

But even if you were the most disciplined writer in the universe and would avoid all these pitfalls, there is another problem over which you have no control. The market has gone through various iterations of devices by now and new generations of devices are introduced on an annual basis, it seems. You have black&white eInk readers, tablets, cell phones, and software readers for desktop computers, not to mention countless cheap eBook readers from China. Each of these devices have their own idiosyncrasies. Their little peccadillos, one could say. iOS devices, like the iPad and iPhone, for example, do not follow the standard implementation when it comes to switching fonts. They also have trouble centering content, requiring special work-arounds. Other devices do not scale images correctly, others yet, like the Kindle do not calculate spacing correctly. The list of glitches and firmware bugs is endless and gets longer with every new device and with each new firmware upgrade.

Your word processor does not care about these. If you’re lucky, it will create an eBook that follows the format standards—though even that is often dubious. It does not, however, take any of these device specific quirks into consideration. Aside from the invisible formatting glitches these exporters are prone to introduce, this is the single biggest problem you will run into when using an exporter to create your eBook for you.

Many authors will check the resulting ebook on their own device, and if its displays correctly, they simply assume that the software did its job properly. This may turn out to be a sore error in judgment. Try loading it on a first-generation Kindle, however, or a Kindle DX, or the Kindle reader on the iPhone, or on an older Nook, or a first-generation iBook device, and very quickly you may see how all your well-laid plans fall to pieces. The only way to address these kinds of problems is to manually identify the glitches and implement work-arounds that address them. There is simply no shortcut for it, no matter how much you may wish otherwise, but with the help of this book you will be able to circumnavigate the most common problems.

The road to Right

After having spent a lot of time up to this point, telling you how you should not create an eBook, I will no longer hold you back with explanations of Wrong and instead will point your heads forward and look down the less rocky road to Right.

Let’s start with a quick overview over the process I am proposing, just so you get a general idea of what you’re going to get yourself into. Depending on your level of expertise, this might or might not be all that intimidating at first, but let me assure you that there is no magic involved, and that every task can be performed by virtually anyone familiar with a computer. Remember, the key lies, as so often, in getting the right tools for the job and putting them to work for you.

The majority of eBook formats that are in use today are nothing more than a packaged collection of HTML files. Yes, the same kind of files used to create and display web pages. Surprised? You shouldn’t be. It actually makes a lot of sense. HTML has been created to allow the same information to be displayed on a wide variety of display devices regardless of their capabilities. Whether your computer monitor has a high or a low resolution, whether you are running your browser fullscreen or in a small window, on an old or a new computer, a cell phone or a tablet, basic HTML pages will always be able to display their contents properly in any of these environments.

The same is essentially true for eBooks. Since we don’t know what device or software the reader will use to read our eBooks, it only makes sense to utilize a format that has been designed for that very purpose, doesn’t it? A format that has free text reflow capabilities and can easily embed images and other media. You might recall how I told you that you can actually embed video in your eBooks if you want to, and now you know, why.

HTML is a format perfectly suitable for the needs of the eBook community and all it really lacks is digital rights management, or copy protection to put it in plain old English. To accommodate that, some of the eBook formats are encrypted internally, but that is really none of our concern at this point. Let other people worry about that. We just want to package our book in a digital format that can be used by eReaders for the time being.

zen Garbage in, garbage out!


ZenCoverThis was an excerpt from my book Zen of eBook Formatting, and I hope you have found it helpful. Perhaps it even convinced you that it might be worthwhile learning more about eBook formatting, the techniques and sills necessary to produce eBooks on a professional level of quality. For much more information and techniques that will help you create professional-grade eBooks, please make sure to take a closer look at the book on Amazon.

If you want to keep up with my eBook formatting work, don’t forget to subscribe to my Newsletter. That way I can keep you updated about the latest developments, updates to my books, code snippets, techniques and formatting tips.

Facebooktwitterredditpinterestlinkedinmail

6 Replies to “Whether it’s for Kindle or ePub—why you should never use an exporter for your eBook formatting”

  1. Catana

    I absolutely love Scrivener for writing, but it’s also the reason I never published my last completed novel. Final formatting for Smashwords and Kindle was always a pain in the butt so I decided to try Compile. Biggest mistake of my life. No matter what I did, I couldn’t get it to format the TOC the way I wanted — links to sections, but not to chapters. That was months ago, and I’ve been wracking my brain for a solution. Every one that has been suggested on Kindleboards and elsewhere has its own set of problems. I’m slightly familiar with HTML, but have generally avoided it where possible, thinking that formatting an entire book with it would be beyond my abilities. So I’m going to buy your book, in spite of some of the hostile comments on Kindleboards. I’m a serious writer, and I’m tired of being hijacked by the sofware I use. Wish me luck.

    • Guido

      I wish you the very best of luck, of course. There is, of course, a learning curve involved, but most authors that tried found that it was manageable. I would be remiss, however, if I didn’t point out that I’d also be happy to format the book for you. 🙂

  2. Murdo

    I would suggest you look at your book in Amazon at the “Look Inside” and you will see some strange text characters that should not be there. Does not reflect well on your formatting skills. I was thinking of purchasing the book but that gave me second thoughts. Hope this comment is helpful.

    • Guido

      I assume you are looking at it in Chrome? For some reason Chrome seems to have introduced an error in one of their last updates which renders the ‌ entity incorrectly. This results in the garbled look that you see. If you take a look at the “Look Inside” feature on Firefox or a different browser you will notice that it actually looks correct. It also looks correctly on actual eBook devices.
      It is very unfortunate that this is going on but it is sadly beyond my control, and I’m not sure I should change my book’s typography just to accommodate a bug in Google’s browser code.

  3. Alicia Butcher Ehrhardt

    Just for an update: I tried looking at your book on Amazon via Firefox on my Mac.

    The graphics did NOT work: every included graphic’s text around your symbol were completely messed up.

    I do plan to use Scrivener -wish me luck – but I do NOT expect one-click satisfaction. I have a bunch of styles, and some ideas.

    But most importantly, I am taking the time to learn HTML and CSS, and will make SURE there is no garbage – by examining to final files, first in TextWrangler to make sure what I think is there, IS there (especially those pesky right margins – Scrivener has no way I can find to, say, indent a block of text on both sides).

    I will go into the epub and mobi files to make sure margins are in ems properly, and everything else is relative.

    There are a lot of tools in Scrivener I don’t see used a lot, such as the fact that you can format for at least 10 levels of folder, file, and file group. It may take breaking my text up into different levels, so that each file gets its own formatting, but to me that is preferable, because how I organize and view my own words in Scrivener is my choice.

    I love Word for what it does well – WYSIWYG – and business letters, but I’m not going anywhere near it for HTML.

    What I’m looking for is to set up everything so I like the way it renders, and then, when I make changes to the text, do the one-click thingy again – but only keep the changed content files from that version. Not the headers, etc.

    You can’t avoid learning what you need to know, but how you get to the final point can be individual.

    If it works to use Scrivener the way I plan, I’ll let you know.

    If not, well, you told me so.

Leave a Reply

Your email address will not be published.