Archive for the ‘ Formatting ’ Category

While you are reading this, Amazon is silently rolling out Kindle Format X (KFX) to supplant the previous KF8 formatting. You may have noticed the little “Enhanced Typesetting” entry on their Kindle book pages, which, when set to Enabled, indicates that the new format is in place for that particular book. Naturally, the new features will be visible only on devices that actually support the new KFX format, and as in the past, Amazon will deliver a downgraded format to all other devices to match their respective capabilities.

AMZEnhancedRight now, it’s still all hush-hush with no official information or documentation available, so everything I am pointing out here may still change going forward, but given Amazon’s track record in that respect, this is highly unlikely.

Welcome to the abominable new world of Kindle!

The actual implementation of KFX is being handled on Amazon’s server backend, which means no extra formatting is required in actual eBooks and not tools are currently required, though that is most definitely likely to change because it makes the creation and evaluation of content a tedium at best and a nightmare at worst. See, currently, only a small portion of books actually supports the feature, each of them picked at Amazon’s sole discretion. See, KFX is not something you actually author, as it is rather some conversion that Amazon is doing on their end to tweak the eBooks on their servers before they are delivered. This means that in order to evaluate KFX currently as a developer, not only do you need to have access to a book that Amazon has deemed worthy and that is offered with Enhanced Typogaphy, but every time you make a change you ill also have to upload the new test-version and wait about 24 hours until the new version goes live and you can see how the formatting behaves under the new KFX engine. It is, quite frankly, a nightmare and a tremendous time sink.

The Kindle eBook format could use some improvements, there can be no question although, with KF8, Amazon has brought the format so close to the ePub specs that one really has to wonder why they did not go it all the way and eliminate the majority of problems that plague the platform once and for all.

Four years ago I wrote a blog post called “10 Things Amazon should correct in the Kindle” and in retrospect it is frightening just how little the problems mentioned there have ever been addressed. As Amazon moved forward with the KF8 format, there were plenty of improvements but in many ways the new format was also a step that made things worse, as outlined in my blog post “Amazon introduces new Kindle eBook format and makes a major misstep“. Once again, nothing was done to resolve the serious problems underlying the format. With that in mind, it is clear that Amazon does not care about existing flaws and all the issues we see emerging right now will plague the format for years and device generations to come.

Naturally, I was curious to find out what would await us with the migration to KFX. Boy, do I wish I had never opened that can of worms.

The Kindle creators never understood books

The problem with Amazon’s Kindle platform has always been that it has been designed and maintained by people who, quite evidently, do not understand books. The device and its firmware has been designed by Lab126, a company that specializes in handheld devices, and the name, Lab126, could not be more fitting, because everything about the Kindle has felt like something put together by lab rats, from day one; people with no sense of the real-world application of their devices. I would not be surprised to hear that the engineers at Lab123 have never really read a book on a Kindle or tried to format one, for that matter.

Farewell to non-breaking spaces

So, what’s the problem with KFX, you wonder? Let’s start with what is, perhaps, the biggest whopper. The Kindle no longer supports non-breaking spaces. This means all those instances where you made sure your text units will remain together and won’t be broken apart, will all be ignored. Line wraps will wreak havoc with your finely crafted “Mr. Smith,” “5 minutes,” “November 5,” “3 p.m.” or the “1964 Mustang,” as they will all potentially be butchered by rampant line breaks, splitting the units into non-sensical individual words. To find this in a device that is designed specifically to display books is like selling a car without a steering wheel.

Decimals are a bitch

But the fun doesn’t end there just yet. Amazon has also fiddled with the hyphenation rules, but instead of making them smarter and more real-world-like, they have gone backwards and implemented an algorithm that conjures up memories of 8-bit computers. Imagine, an algorithm that treats every period as a point where lines can wrap. Suddenly you will find that “FM 99.8” becomes a garbled mess where the number 8 ends up on its own line. Forget about scientific texts with decimal notation or website names with a dot-something extension. They all can now be brutally butchered beyond comprehension. What an awesome improvement… what an “enhanced typography.”

Another such issue can be found when it comes to em- and en-dashes. The new KFX implementation is suddenly teaching the Kindle layout engine to do line wraps before the dash, as well as after. If I didn’t know any better, I would almost believe that Amazon wants to rewrite typography rules with botched features such as this. These problems clearly show a lack of understanding of the subject matter and a wholesome disregard for everything relating to book design.

The list goes on, and as we will be exposed to an increasing number of KFX-formatted and rendered books, I have no doubt that more problems will emerge and we are only but scratching the surface. It makes you wonder, where exactly are the “enhanced typography” features that Amazon is touting?

So where exactly is the “enhanced typography?”

Well, nowhere, really. Text flow has not been improved from what I can tell, and word spacing issues have still not been addressed, while tables still remain unusable. While it can finally hyphenate, in a kind-of sorta way, when justifying text, the Kindle will still only expand word spacing and it will never ever reduce spacing the way you would do in a print book. As I said, the layout engine operates on the level of a Commodore 64 8-bit computer. This is incomprehensible because handheld devices are so powerful these days that highly sophisticated algorithms could be put to use that would properly evaluate line widths and adjustments to them to create visually pleasing layouts. Instead, the Kindle is still simply dumping text on the screen without any regard for typography.

The Kindle still suffers terribly

Simply introducing a new typeface and a few ligatures does not make for enhanced typography. The Kindle still suffers endlessly from widowed words, orphaned lines, inaccurate spacing, ignorant kerning and other problems galore.

A bright light…images…perhaps!

And then there are the images… For the longest time, Amazon has ignored image transparency in PNG files and in recent years they have given us a completely borked 8-bit PNG implementation that resulted in nothing but black blocks. With KFX we can now celebrate the arrival of their new JPG format, JPG XR. In and of itself, JPG XR is a wonderful development, a useful enhancement to the standard JPG format that results in smaller images with less loss in definition. With this new image support in place, Amazon is now converting all images in an eBook into JPG XR format, including all GIF and PNG images, as well as SVGs. Like they did with the KF8 format, Amazon is also creating dedicated versions of a book for devices of varying capabilities. As a result, they will now convert images to grayscale for delivery to monochrome Kindle devices, once again a step to curb in bandwidth – and thus, reducing the cost of delivery fees for you.

But there is an inherent danger in doing this and given their shoddy track record, I am not entirely sure Amazon or Lab126 have gotten the memo how to properly utilize JPG XR. Normally you would not want to convert a line art image, like a PNG, to a JPG format, but since JPG XR features a mode with lossless compression, this may no longer be true. At this time I am not entirely convinced, however, if the KFX backend is taking this into consideration, or if PNG images are simply converted to regularly compressed JPGs. As more samples emerging over the coming months, I am sure we’ll find out soon enough. Regardless of compression issues, however, at this time it is clear that Amazon is once again completely forgoing all image transparency, completely ignoring the alpha-channel support that the JPG XR format offers. So even in 2015, the use of images in eBooks appears like a clunky, broken relic of – yeah, you guessed it, the 8-bit era.

Once more, Amazon is hopelessly missing the mark

When you want to create a format that lauds itself with “enhanced typography,” the first thing you need is to have people on board who understand typography, and to Amazon’s shame this has evidently never been the case in the Kindle department, ever. The company and Kindle-developer Lab126 are stumbling from one mistake to the next, making things worse with each incarnation. Rather than finally investing some time and actual experience in the platform to hammer out a “real” eBook format, really useful eBook features, and real eBook-ready firmware, the companies still seem to leave the job to code jockeys.

With each iteration, it gets harder to explain away the ineptitude displayed by the people creating these implementations. The shortcomings of the first-generation Kindle could still be attributed to weak processing power, limited display technology, and the journey into completely uncharted waters, but in today’s market, Kindle users should expect a device that has been honed to perfection, not a tinker toy gadget that continues to miss its marks and its core audience by a mile or two.

If you thought Smashwords’ Meat Grinder was a monstrosity, welcome to Monster X and the abominable new world of Kindle!


With the lowering of the barrier of entrance, self-publishing books has become the norm rather than the exception. Something that was traditionally handled by big, lumbering publishing houses or by individuals with a lot of money, has now become a reality for anyone. It no longer has the stigma of vanity publishing, but has instead evolved into a perfectly viable route to market.

But the fact that it is easily possible does not mean that it is easy to do. There are countless pitfalls along the way, and for someone who has never even had tangential contact with the publishing industry there are inevitably a good number of lurking misconceptions. The number of decisions that have to be made, and the impact these decisions can have on your potential success are immense.

Choosing the right cover is perhaps the most important decision you will make surrounding your book

Let’s take a look at book covers, for example. It is so easy to get them wrong—and for all the right reasons.

For many years now I have been working with authors who self-publish their books. I have been formatting their books, as well as providing cover art for them on many occasions, and if there is one red thread that weaves itself through the nearly one-thousand book projects I have worked on, it is this: passion!

Authors spend a lot of time writing their books, massaging them to perfection, editing them, reading them again and again, proofing them, the whole spiel. It takes a lot of time and passion, naturally, and as a result authors always have a very close attachment to the project. A lot of passion. It is the essential ingredient or else the project would never have come to fruition.

Don’t let the fact that you are, perhaps, too close to the project cloud your judgment

However, this passion can easily become detrimental when it comes to certain aspects of the actual publishing of the project, because publishing a book requires a number of business decisions. A cool head is required to make the right choices, or you might get in the way of your own success.

Covers are one of the areas where these problems often manifest themselves very quickly, creating a dangerous slope, because covers are, perhaps, the single most important decision you will ever make regarding your book.

So, let me ask you this question… what is the purpose of the cover?

The purpose of a book cover is not to perfectly illustrate the story down to the smallest detail or to showcase every aspect and facet of the plot. If you think this way, you are too close to your project, and you are thinking about your cover too literal—especially in the digital world where books are bought primarily online and the presentation of the cover has changed from a beautiful piece of art to a small 100 pixel-wide thumbnail.

The sole purpose of a book cover is to help sell the book

A book cover is a selling tool! Nothing more, nothing less. It serves the purpose to attract eyeballs and then get those people intrigued enough to click on the cover thumbnail and learn more about the book, which, hopefully, will then result in a sale. If visitors on Amazon do not notice a book cover because it is easily overlooked and disappears among other covers, it serves absolutely no purpose and is actually detrimental to the author because uncounted potential sales are lost right there.

Forget how much you love your friend’s illustration, or how you feel this frilly font really reflects your main character’s taste for the intricate. If people do not notice your cover or if it is muddled up, you won’t make a sale.

You always have to keep in mind that for the most part you are trying to sell books to people who are not familiar with you and who do not know the book or the story—at all. It is the cover that will hopefully draw them to it. It is the cover that will hopefully connect with them and intrigue them enough to find out more. Only then will you be able to tap into new readers. Readers who are essential for growing your customer base not only for this book, but also for your next.

A good cover will open your book up to a new readership

I suppose it is easy to see that the impact one good cover can have are very far-reaching over the course of a writer’s career.

What makes a good cover then?

Again, with the digital revolution, software has become available to anyone with a computer that enables us to do everything by ourselves. But should we? A better tool does not necessarily mean the output is getting better. Even with a better knife you will still not be able to carve a better statue, because you lack the necessary skill set, and you really have to ask yourself whether you feel that you are qualified enough to tackle something as important as your book’s cover by yourself.

Among many things, I am a trained typesetter. I took a three-year apprenticeship to learn about fonts, their impact, their structure, the creation and design, and the subject of printed matters on the whole.

This apprenticeship taught me things that allow me to make educated decisions when it comes to the visual presentation of the written word. Which font to choose, which size to choose it in, how to properly kern it, how to adjust and tweak it for best visual impact or for best readability. The list goes on.

Covers are not just an image with a few words sprinkled on for good measure

See, it is a very common misconception that covers are just images with a handful of words thrown on them. Nothing could be further from the truth, really. A cover needs focus. It needs to create intrigue. It needs to guide the eye. It needs to create emotions that connect the story with the person browsing the virtual bookshelf.

Do a little experiment, if you wish. Do a search on Amazon that should bring up your book, and then quickly scan the results with one glance. If your book is not the first one that jumps to your eye, your cover is missing something. How could I say something like this? Because you are so familiar with your cover that your eyes should immediately pinpoint it—with your eyes closed, almost. If they don’t, you know that something is seriously wrong, because the odds of a stranger honing in on your cover at a glance are deteriorating rapidly here.

Aside from the cover motive itself, font choice is vital. A font that is unbalanced and hard to read is useless, but what is “unbalanced” and what is “hard to read?” These are the things that typesetters and graphic designers have spent years learning and studying. A well-chosen font on a single-colored background can be extremely dramatic in the hands of the right cover designer. It can cut to the chase and deliver its message, and that is exactly what you need. That is what trained professionals are for, and access to trained and professional talent is easier and more affordable than ever.

If you can’t see your cover, no one will

Though custom designed covers are still quite pricey and not within everyone’s budget range, a new alternative has emerged over the past years—pre-designed covers. One of the players in the field of pre-designed covers is my most recent venture,, where I team up with experienced long-time graphic designer and illustrator Lieu Pham to bring bestselling book covers to authors at affordable rates.

The concept of pre-designed covers, or premades as they are often called also, is very simple, really. The cover designer creates and hosts a catalog of covers that have been prepared ahead of time, without any particular book in mind. These covers are usually following themes and trends that reflect the current state of the market, without honing in on exact details of any one book. This way the cover can be potentially applied to a variety of books, because it illustrates more general subjects, while maintaining the high quality and professional design elements you would normally find in much higher priced custom designed covers. Reputable designers will make sure that the covers remain nonetheless unique, by selling a particular cover design only once. In these cases, after it is sold to an author, the cover design is taken off the market, and no longer available to others.

Predesigned covers are a cost-effective and fast way to get that professional look

This kind of service should not be mistaken with supposed cover designs you can get on sites like Fiverr. These are usually not created by professionals, but hobbyists with extra time on their hand, and therefore often lack in real design and typography fundamentals, not to mention that many of them are using imagery without obtaining proper rights clearance, etc. A professional cover designer will always ensure that the images used will be legitimate and will not create copyright nightmares for you.

So, if you are a writer, looking for an affordable cover for your next book, while making sure it plays on a professional level and doesn’t break the bank, a pre-designed cover might just be the ticket. In addition, pre-designed covers have a very quick turn-around, because they can be finalized with your book title and handed over to you much faster than a custom job. Reputable designers will get the final cover to within a day or two. This means no delay for your project, so you can go to press anytime you’re ready!

On my partner Lieu Pham, a long-time graphic designer and illustrator, and I are offering covers for a wide range of genres, in a wide range of themes and looks, all optimized for best discoverability, all making a statement and an impact, and we strive to give each pre-designed cover the same kind of feel that we afford our custom design projects. Sound interesting? It should, because getting professional covers has never been easier.


Teaching TextMate a new trick

I recently had to switch to TextMate 2 because I had upgraded to OSX 10.10 Yosemite, and my trusty old version of TextMate was no longer fully operational. Some of the bundles I am routinely using when formatting eBooks crashed Ruby, making them useless.

One of the features I constantly use is the “Wrap Each Selected Line in Open/Close Tag” command from the HTML Bundle. It is one of the most important commands I use when formatting eBooks, because it allows me to automatically wrap every paragraph in a text in <p> and its corresponding </p> tags.

After the update to TextMate 2 I found, however, that the functionality was no longer what I really expected. Instead of wrapping everything in <p> tags, I found my text wrapped in <li> tags instead, which was not very useful. Actually, it was not useful at all. It was detrimental.

I’ve done a little bit of TextMate Bundle coding myself in the past to create streamlined commands that help me format eBooks much faster. They have become essential part of my everyday tool chain. Seeing the unexpected behavior of the TextMate 2 bundle I decided to simply dive into the Bundle Editor and change the default behavior of the “Wrap Each Selected Line in Open/Close Tag” command to my needs.

If you want to do the same, here’s how you’d go about it. Simply open the Bundle Editor by selecting “Edit Bundles” from the “Bundle” menu in TextMate. Next, select the HTML entry in the list that appears on the left hand side of the window. You will now see a number of entries appear in the second column of the window. We want to drill into the one called “Menu Actions” and then the one called “Wrap Each Selected Line in Open/Close Tag”.


In the lower window that contains the code portion of the command, you will find the following lines

[[ -f "${TM_SUPPORT_PATH}/lib/" ]] && . "${TM_SUPPORT_PATH}/lib/"
perl -pe 's/[\$`\\]/\\$&/g; s/([ \t]*)(.+)/$1<\${1:li}>$2<\/\${1\/\\s.*\/\/}>/'

As you can see, in the jumble of the regular expression there is a reference to the unwanted “li” tag. All we have to do is change that entry to “p” instead and make the line look like this

[[ -f "${TM_SUPPORT_PATH}/lib/" ]] && . "${TM_SUPPORT_PATH}/lib/"
perl -pe 's/[\$`\\]/\\$&/g; s/([ \t]*)(.+)/$1<\${1:p}>$2<\/\${1\/\\s.*\/\/}>/'

Once you’ve done that, hit Ctrl-S to save the change, and you’re done. Whenever you now press the Shift-Control-Command-W keys or select “Wrap Each Selected Line in Open/Close Tag” from the Bundle menu, every paragraph of your text will be neatly wrapped with the correct <p> tags.


Over the past weeks I’ve been reading a number of non-fiction eBooks—don’t ask me, why, it just happened for some reason. The interesting thing is that I noticed a number of recurring eBook formatting problems that permeated virtually each one of these books, and I thought I’d touch upon the subject for a change.

The problem in question revolves around terms that should be treated as a unit. Take a look at the screenshot and see if you can figure out what’s wrong with it.


The problem her is, of course, the way the term “30 days” has been line wrapped—twice actually, and the term 1,667 words has been wrapped also. Plenty of bad formatting going on here!

When you have something like this term, a professional typesetter will always make sure that the individual words in the term will not be word-wrapped… ever. There is nothing worse than having the number “30” on one line and the word “days” on the next, or worse yet, on the next page. It just doesn’t look professional and instantly gives off a whiff of amateur that you do not want in your book.

Certain terms need to stick together like Laurel and Hardy

In novels this is oftentimes not such an acute problem, because most authors would actually write “thirty days” instead, which can be wrapped perfectly fine, but by their very nature, non-fiction books often wrangle a lot of data and as such it is no surprise that I found the error striking in the past weeks in particular.

Naturally, the same applies to terms,such as “3 months,” “4 years,” “5 minutes,” “10 dollars” and so forth. Other occasions where you may find terms that should never be wrapped is in dates, for example, such as “November 5,” “Day 3,” “3 AM” or even in situations like a “1964 Mustang” or a “1953 Corvette.”

The most prevalent occurrence of such terms, in both fiction and non-fiction is on cases, such as “Mr. Potter,” “Mrs. Bates,” or “Dr. Jekyll,” and one could even go as far as applying the rule to terms such as “Agent Mulder.”

The solution to the problem is fairly simple, really. If you are formatting your eBook in HTML, you simply replace the space between the words of the term with a non-breaking space character, like this: 30&nbsp;days. This way, you disallow the eBook software to break apart the entity.

The solution: Prevent word-wrapping with non-breakable space characters

To achieve this one can use a very simple Regular Expression to isolate the cases. The concept is to search for one of multiple digits, followed by a space character, followed by a letter.

A simple search expressions like this

([0-9]) ([a-zA-Z])

will locate such instances. I do not recommend simply running a replacement on this search, however, because there would be too many false positives. Instead, simply go through them one by one and decide whether they need to be adjusted or not. I know, this is time-consuming, but that’s part of the reason why professional ebook formatting costs a bit of money.


As you know, I do not recommend exporting eBooks straight from word processors, but I do understand that many authors do so nonetheless. It is possible to avoid this kind of word-wrapping in word processors as well, by replacing the space character with a Ctrl-space character. And voilà…

If you can actually make this practice to use Ctrl-space in all the right places part of your general writing habit, all the better, you will be properly prepared right off the bat, and you will make the life of your eBook formatter a whole lot easier.

The thing about this kind of eBook formatting error is that it is not something that readers would report to you, but it is wrong nonetheless. It gives authors the impression that nothing is wrong with the eBooks, when, in fact, there are formatting errors in it. Many such issues can be evidenced in eBooks, pitfalls that most people are not aware of but that hinder the reading flow and somehow give off a bad impression.

That’s why it make sense to hire professionals to handle your eBook formatting. Someone with credentials, someone who understands actual typesetting, in order to make sure these kinds of things don’t happen.

Will you take a look at your books and see if you’ve been a victim of this particular pitfall?

Zen of eBook Formatting is currently on sale for only $2.99 instead of its original $5.99 price!

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.


For all my author friends and visitors, today I have an announcement that is slightly different from my usual formatting posts. I would like you to check out a brand new website called!

As the title suggests, it is a website specializing on covers. Selling book covers, to be more specific, and if you want to be exact about it, is a destination where authors can find highest quality pre-designed covers as well as custom created covers.

Why am I telling you this? Well, if you browse the site a little, you will notice that my name comes up, because I am affiliated with the site. As part of the packages for authors offered on I am throwing my formatting experience and services in the ring, so that hopefully it becomes more of a one-stop solution for authors. Here, you can get your eBook and print covers done, as well as your eBook formatting and print layout. All easy, quick and super professional. Here are a few samples I picked for you, just to show you the level of quality you can find there.

Needless to say there are countless more covers available for purchase right now! If you don’t believe me, just browse some of the pre-designed covers that are currently available on the site. Whether you’re a romance, horror, mystery or thriller author, or if you write non-fiction and self-help books, anything in-between, on you can find an ever-expanding array of pre-designed covers of the highest quality at affordable prices.

But there is more… in addition to the covers themselves, also offers additional graphic assets for your books, including web ads, Facebook banners, memes, 3D book covers images, audio book covers, bookmark and postcard designs—all designed to help promote your book.

It is very easy to see the decades of design experience shine through in these covers, as they have been tweaked for optimal visibility. Since books are bought primarily online these days, every cover has been carefully designed to ensure that the respective books will get noticed by readers browsing virtual store shelves. Don’t believe me? Go, see for yourself. Right now!

Oh, and before you leave, make sure you will also tell all your friends about, because undoubtedly, they will need a best-selling cover for their next book as well, and wouldn’t you like to be the one to set them on the right path?

I am making it easy for you! Simply click on the text or the icon below, and tweet the news to all your followers.

Tweet: is a new hot new site for all your pre-designed #eBook and print cover needs — #covers
Click2Tweet: is a new hot new site for all your pre-designed #eBook and print cover needs — #covers

Custom fonts in iBooks

By now, I am sure you’ve heard that every device in the market has its own little quirks. Whether it’s not scaling images correctly, ignoring transparency, overlooking style settings in certain tags or some other weird behavior, the process of formatting ebooks across platforms is anything than straight-forward.

Today I want to direct your attention to one issue in particular, the way iBooks is handling font switches. Ordinarily, and on all other platforms, changing the font in a block of text is one of the most rudimentary and trivial things to do. You would set up styles and then use a, <p>, <span> or <label> tag to switch the style and consequently the font type with it, just as outlined here with these style settings…

span.sans-serif { font-family: sans-serif; }
span.serif { font-family: serif; }
span.monospace { font-family: monospace; }

…and the following HTML paragraph.

<p>This is an example for a <span class=”sans-serif”>sans-serif font</span>, while this is a switch to a <span class=”monospace”>monospace font</span> and this here a quick look at a <span class=”serif”>serif font</span>.</p>

Unfortunately on various occasions, Apple has decided, for unfathomable reasons, to break with convention and create implementations that are more tedious than they really need to be. The approach I just illustrated is not working in iBooks—or rather I should say, it is not always working. Especially when you use embedded fonts that are included using the @font-face rule, you will find that they simply do not show up.

There are two small additional steps that are necessary to get iBooks to properly display your fonts, though small they may be, they are also incredibly cumbersome.

The process involves getting inside the actual ePub file and adding information. Fortunately Calibre lets us do that fairly elegantly, but it is nonetheless a tedium because you will have to do this every time you rebuild your book.

When you right-click your book in Calibre a context menu appears and you will find an entry called “Edit the book” at the bottom of the list. Naturally you will first have to build an ePub version of your book for this to show up, but when you select it, a new window will open showing you the structure of the eBook on the left hand side and the file contents at the center. You now have access to the internal structure of the ePub file, which is a packaged-up assortment of individual files, actually.

In the Files Browser window on the left side of the screen scroll down to the Miscellaneous area where you will find a file called content.opf. Double-click that file and its contents will be displayed in the large window at the center of the screen.

Now enter the following code in that file

<meta property="ibooks:specified-fonts">true</meta>

Best place it right at the end of the <metadata> section just before the closing </metadata> tag.

Now comes the trickier part. We actually need to include a completely new file. First open up a text editor and create a new text file. There, enter the following lines

   <platform name="*"> <!-- allowed values for platform "iphone", "ipad", or "*" for all -->
     <option name="specified-fonts">true <!-- must be set to "true" for embedded fonts -->

and then save the file as Alternatively, simply right-click this link and save the file to your computer.

addbtnWith the “Edit Book” details page still open in Calibre, click on the “New File” icon in the upper left corner of the window.

Now enter meta-inf/ in the dialog box and then click on the “Import resource file” button. Locate and chose the file just we created and hit the “Open” button, followed by “Okay.” You will now see that the file is appearing in the “Miscellaneous” section of the book structure.

savebtnNow save your changes and close the “Edit Book” window. Back on the Calibre main screen, hit the “Save to Disc” button to save the modified ePub version to your computer.

That is it. You now have properly embedded the necessary information in your ePub file that makes it possible for iOS devices to correctly display different fonts.

If you do not use Calibre, you can also make these changes by hand. All you have to do is unzip your ePub file using whatever software you would ordinarily use to unzip a regular ZIP file.

Once completed, you will find a subfolder on your computer, containing the individual files the eBook consists of. Locate the file content.opf and make the same changes I described above.

Then navigate into the meta-inf subfolder and place the file in there. The process to create or obtain the file is the same one I described earlier.

The changes are now complete, but will have to zip all these files back up into an ePub file.

This is best done using a command line version of your zip tool. Once you have opened a command line or terminal on your computer, navigate to the directory where your actual eBook files are that you need to zip up. Then enter the following command.

zip -X0 mimetype

This creates the base package for the eBook. We now zip all the content files into it using the following command

zip -rDX9 * -x "*.DS_Store" -x mimetype

Once this is complete, you will see a new file called in the folder. All we need to do is rename it now. If you are working on a Windows computer, simply enter the following command.

ren title_of_your_book.epub

Alternatively, if you are working on a Mac, the following command will do the trick

mv title_of_your_book.epub

That’s all there is to it. Keep in mind, however, that these steps will have to be repeated every time you rebuild the book!

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


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.

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

A much better way is to take control of your eBook files yourself. Instead of relying on exporting them, which is a hack and a shortcut at best, properly format them yourself. Use methodologies that have proven to work across platforms, such as the approach I outline in my “Take Pride in your eBook Formatting” tutorial series and my book “Zen of eBook Formatting,” which is a step-by-step guide from the most basic beginnings to fully advanced eBook layout features. Feel free to download a free reading sample on Amazon and see for yourself.

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

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.


As self-publishing, independent authors, to typically relish in the freedom we have suddenly be handed, allowing us to truly own our books, cradling and nourishing them from the very first word, all the way until we usher them out the door through self-publishing platforms such as Amazon or Barnes&Noble.

SelfPubI am sure you’ve heard the saying before, that freedom is never free, however, and while not really meant within that context, it is certainly true for self-publishing authors and contains a nugget of wisdom we should all take to heart.

As a self-published author myself, I know how much work goes into a fully finished product, even in an all-digital world. As an eBook formatter for hundreds of independent authors, I also constantly witness the struggles and problems that authors fight. Whether its questions arising on my formatting blog tutorial, my book Zen of eBook Formatting, or through email, I am witness to the tribulations of many writers. Since I am also a reader, constantly looking for new books to feed my mind, browsing Amazon’s Kindle section further helps me understand the situation that presents itself to self-published authors.

This biggest question, I believe, every self-publishing author needs to ask themselves is this: Simply because we can handle everything ourselves, does it also mean that we actually should do so?


Writing a book is one thing. Editing a book is a different thing entirely. Too many authors either do not understand the process of editing, or they discount its value. Having a bit of ego is good if you’re a writer, but do not let it interfere with your actual work. It is fine to love what you are writing, but make sure you never fall in love with it! What I mean by that is that if you get to the point that you believe no one should have a right to touch your writing, that every comma is exactly where it should be, and that every word in your prose is perfectly concise and where it should be, the odds are that you are overestimating your abilities.

BookEditingEven Mark Twain had an editor. He did not like it, but he did. What he realized, however, is that a different set of eyes brings out shortcomings in writing. Ambiguous expressions, sentences that may not be quite as clear as they were in the writer’s mind, and much more. Even the best writers jump to conclusions because they have this picture in their mind that they try to relay to paper. The picture in their mind is complete in its own way, so they fill in the words to describe the image. But every once in a while, the writer will overlook a small detail that he takes for granted because of the image in his mind. An editor can help in such cases, pointing out the omission or simply helping to clarify the written words through different word usage or sentence structures.

The problem is that too many authors see an editor as the enemy, which they are not. Too many authors see editors as critics with the sole malevolent purpose to tear their work apart and violate it. In the self-publishing world, nothing could be further from the truth. Look at an editor as a fresh set of eyes who can help you streamline your writing, creating a better experience for your readers. After all, you are paying the editor, which makes it perfectly okay for you to reject their comments. There is nothing wrong with looking at the notes of an editor and flat out rejecting some of them because they misinterpret your intentions. But for every one such case, I am certain you will find countless others where the editor’s suggestions will make you think about your writing some more, and perhaps improve it as a result of it. so, why would you want to miss an opportunity to make your writing better?

Proof Reading

A lot of people mistake editing for proof reading, when they are, in fact, two very different things. Naturally, a lot of editors do correct typos and spelling errors, because it often comes naturally as they go through your words with a fine-toothed comb. However, their job is to look at the meaning of your writing, not its fundamentals.

proofreadingThat’s the job of a proof reader, who will ignore all things related to style and grammar, but will instead scan each word in your manuscript to make sure it is spelled according to dictionary standards. This requires a special skill set, different from an editor’s, because a good typesetter is absolutely dictionary proof, which means he has internalized the correct spelling and exact meaning of roughly 500,000 words, plus all of their proper tenses, inflections and cases.

You may confuse your word processor’s spellchecker with a proof reader, but they are not the same thing either, because the spellchecker only looks if the word as such is a valid spelling. It does not determine, whether you are using the proper spelling for the respective word you are trying to us. It will gladly accept the word “hair” instead of “hare,” whereas a proof reader will catch this error and correct it for you.

Having a book that is free of spelling errors and typos is the epitome of publishing and should be every author’s goal, always.


Also high on the list is the formatting of eBooks—and the creation of a print layout, for that matter. Once again, you are looking at very specific skill sets here, and unless you do have the technical wherewithal and understanding of what eBooks are, what their technical implementation looks like and what the resulting limitations are, it might not be advisable for you to tackle this end of the publishing pipeline yourself.

zencoverAs you undoubtedly know, I’ve long been an advocate for proper eBook formatting, trying to enable authors with my Take Pride in your eBook Formatting blog tutorial, as well as my book Zen of eBook Formatting.

However, the field of eBook formatting is becoming trickier by the day, and more and more it requires very specialized skill sets and knowledge. With every new eBook reader in the market, with every update to the software readers Amazon, Barnes&Noble or Kobo offers, and with every new cell phone and tablet that enters the market,the playing field becomes harder to control.

When the Kindle was first released, things were easy because it was the target platform. In today’s world Kindle is not even Kindle any longer. There are so many device generations, each of which behaves differently, and there are so many software Kindle readers, each with their own flaws, that formatting a book for the Kindle alone can be a tremendously challenging—and time-consuming—task, depending on your book. But the Kindle is no longer alone. There is the Nook in its countless iterations, there is the Kobo reader, there are hundreds of cheap knock-offs from China… the list has gotten endless. To ensure that a book displays absolutely perfectly on all devices has become a magic trick, almost… something that is almost unattainable for certain books, because there are too few control mechanisms in the eBook format themselves.

And yet, nothing upsets a reader faster than a shoddily formatted eBook. It may just be the number one reason why readers put down a book prematurely, because they cannot see beyond the flawed text flow, the jumping margins, the inconsistent text size, the lack of proper quotes, or the broken indentations. And once a reader has put your book down, the odds are they will never pick it up again, and, what’s even worse, they may never buy another one of your books in the future.

Naturally, for all these services you can hire professionals whose job it is to make sure your work is treated professionally. These collaborators will help you on your road to a successful book with their advice, experience and services. It is for that reason that I have been offering eBook formatting services to authors and publishers for many years; to make sure that digital books will get the same respect as their print counterparts.

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 book, code snippets, techniques and formatting tips.


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.

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