Archive for
March, 2015

On many occasions I’ve kept repeating that it is generally not a good idea to use word processors to export eBooks directly, and whenever I make that statement I am frequently greeted by push-back from authors who are perfectly happy doing it because it works for them.

I guess the operative phrase here is, “works for them.”

Exporting a clean manuscript from a word processor can work if you are dealing with a novel that has nothing but the most basic formatting. I have to point out, however, that not a lot of the books I work on for my clients fall into that category and typically have a few formatting features that require more attention to detail.

In these conversations I have with authors, a lot of folks also seem to think that Scrivener is the ultimate solution and does a perfect job exporting eBooks, a notion that I am going to shred in a moment. First, however, it is important for me to point out that I am a huge fan of Scrivener. I have used it for years. I have written 15 books in Scrivener and I would not consider any other software for the task. I have, however, never considered it to be an eBook exporter. It’s my writing software. Nothing else.

I am saying this because I want you to understand that it is not my intention to discredit Scrivener here. Rather, I want to debunk the myth that Scrivener’s eBook export is perfect and want to show a simple example in which Scrivener’s eBook exporter can completely destroy your eBook.

Imagine, if you would, that you have a small quote you want to format so that it is right-aligned on the page. However, since it is a quote, you do not want it to run the entire width of the page. To make it look nice and neat, you want it to run just, let’s say 20em wide, so that it turns out to be a neat little block of text on the right side of the page.

In Scrivener – or any other word processor for that matter – you would select the text, turn on right-alignment and use the ruler to scale down the width of the printable area. Alternatively, you could have a prepared style that does the same thing, of course, and simply apply it to the text. Makes no difference. The key here is that in order to achieve the proper limited-width word-wrapping, you will have to adjust the printable width.

It looks neat and nice, right? Just until you export it.

If you export a section like this to an ePub file, you will find that your page is mysteriously empty. That’s right. There won’t be anything on the page. What is happening?

In order to understand what is going on, it helps to look at the ePub file that Scrivener creates, and very quickly it becomes obvious that it fell into a major format trap.

Because of limitations in eBooks, in order to create the 20em text canvas on the right hand side of the page, Scrivener decided fake it by simply increasing the left hand margin. It’s a valid approach, no doubt. If you think of the entire page width as 100%, increasing the left margin to 80%, leaves 20% for our quote to be printed. The logic is fine. The execution is not.

First of all, we are not working with percentages. Why? Because if you are looking at a cell phone screen, there is a good chance that 20% of that screen width would barely fit a single word. We cannot allow that to happen. We need something that relates to the text size first and to the display size second.

To accommodate the problem, Scrivener decided to lay it out using em-spacing, which is exactly as it should be. The problem is that it looks at the actual page inside the Scrivener window to calculate the page width. Since the windows on my computer desktop is a lot wider than that of a cellphone screen or even a regular eBook device, the measurements are all off. Scrivener creates a left margin of 80em, and as a result our actual quote is printed off-screen in its entirety. That’s why you see an empty page.

This is just one example of the unforeseen pitfalls you can run into when you simply rely on a software exporter to do the work for you. There are a myriad of other problems lurking to pop up when you least expect it. These software exporters are great at doing the grunt work, but they are exceptionally poor when it comes to create output that is actually compatible with real-world applications.

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.

Also, don’t forget to check out my book Zen of eBook Formatting that is filled with tips, techniques and valuable information about the eBook formatting process.

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.

The 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.

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.

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.

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.

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.

Garbage in, garbage out!

This 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.