Blessed by the Potato

[Back to the first post in the Value of Simple self-publishing behind-the-scenes series]

Electronic books have really brought the cost and effort needed to publish a book down. There is very little overhead or initial investment needed to publish an ebook — zero if you do everything yourself, though you’ll likely want to outsource some things (e.g., editing and cover art). Some places will charge to convert your book into an ebook and list it; IngramSpark for instance charges $25 USD to convert and publish your ebook, though there’s no additional charge if you do it at the same time as publishing a print book (though they do take a larger slice of the royalties). However, you can fairly easily do all of this yourself.

The low overhead for e-books also translates into a relatively high royalty rate (~70% for Kobo and Kindle, ~60% for some other platforms, ~40% if you use a service to automate some of these steps for you — assuming your book is in a “normal” price range).

Formats

There are two basic ways to create an ebook: to use a reflowable text-based format, or to use a PDF. While PDF has become a standard for displaying all kinds of documents across the web, it is near impossible to buy an ebook in PDF format: Amazon, Kobo, and iBooks only offer reflowable/text-based formats (ePub/mobi or proprietary analogues). Google Play apparently allows PDFs, but the customers are not on Google Play (also, Google Play only offers a 52% royalty rate).

The ePub format is the base, standard ebook format, and will work on nearly any device (Kobo, Nook, Sony e-reader, plus many phones and tablets with reader apps), and is close enough to the Amazon Kindle format that you can convert from it with automatic tools and it will work pretty well. The format is basically a self-contained package of really basic webpages (it’s not quite standard HTML but close enough that if you know how to use tags you’ll be fine) and associated images. Each chapter will appear as a separate sub-file inside your ePub, with a common CSS style sheet to create the formatting.

The neat thing about e-books (ePub or Kindle) is that the user has a lot of control over their reading experience: if their eyesight isn’t so good, or their device screen is small, they can bump up the text size or the spacing; they can adjust the margins, and even change the font face. For you, the publisher, the upside of this is that you don’t need to put much work into formatting because the user will just break it anyway (unless you’re a design nut in which case not having control over your layout is probably a downside). The downside is that ePubs are really only suited to text-only (or mostly text) books. They do not have the ability to display tables, and images can be really frustrating to work with. Plus the formatting doesn’t understand percentages, so if you want to indent some text (like the little summaries at the end of several chapters in The Value of Simple), the indent is set in ems, which can create a really narrow little column of text on a small screen (as most of the total space ends up being the left and right margin of my indented summary), and on larger high-resolution screens the indent is very modest.

Years ago, I had to create my ePub by converting my book to html, then using a special creator/editor program to convert that to ePub, then use the editor to fix all the conversion errors. It was several days of coding (every special character wonked out, plus other bugs). Now, Calibre is here and does a much better job of converting directly from Word. I had to tweak a few things — like images, tables and indented paragraphs — but the automatic output was passable. To make my life a bit easier converting, I did some of the work in Word first by creating a new document with the page size equal to the screen size of a 6″ Kobo, and replacing all tables with images. Though don’t trust automatic file converters to do an awesome job — check the code and output yourself.

To get around the limitations of the format, you have to convert any tables to images. However, images are still limited: you can’t simply say “100% width”, the image will by default just display at its native resolution, which may look great on a Kobo Touch, and tiny on a Kobo Aura HD. To get around this you’ll have to manually go in and create frames around each image to tell it to scale to 100% width, using the appropriate aspect ratio (see code snippet at the bottom).

As if that weren’t tricky enough already, you have to deal with the limitations of the readers: older readers had lower resolution than more recent entries. The typical way to deal with this is to put in a high-resolution image and downsample it (shrink it) for smaller screens — going the other way doesn’t make sense, as you can’t create resolution (outside of crime dramas). However, the thing is older devices like the Kobo Touch have crappy graphics processors to accompany their crappy screens. That means a high-resolution image resized (shrunk) to fit on the Kobo Touch looks way worse than a low-resolution image designed for the Kobo Touch blown up to fit on an Kobo Aura HD.

Speaking of limitations, keep in mind that e-ink e-readers are black and white — if you have graphs or other images with colour, be sure they translate to greyscale (I had to redo a few images), and update the figure descriptions to match. Be sure to try to get your hands on a few different pieces of e-reader hardware to see how your book will look on them.

A minor issue with the ePub format is that there are so many little code tags in so many sub-files, and for some reason different retailers will throw up on some for no reason at all, making you fail file validation (after I got it working for Kobo and Google, SmashWords ended up not liking a meta tag in the header — how it can decide one meta tag of several breaks validation, I do not know).

If you’re creating a print version anyway, you may have spent a lot of time on layout and fine formatting, plus have high-resolution images available. In that case you may want to publish a PDF, as I did. Though plenty of readers want one, other than through Google Play I don’t know how to sell them one, so I created my any format ebook bundle that I sell directly through my website, where I have control. Of course, that was many, many hours of setting up a PayPal account to accept credit cards, a ZenCart instance, and dealing with the odd customer issue with the web store. The effort has paid off, I think: it’s my second-most popular sales channel, and my effective royalty rate is higher (I have to pay for hosting, but I do that anyway, and credit card transaction costs).

Writing

Of course, you don’t actually start by writing directly into an ePub or PDF, you start by writing in a word processor, most likely Word. My biggest, most important tip is to use styles when you’re writing to control the formatting. I covered this in the part on writing, but it’s important to repeat as your ePub conversion will pull from these styles — they are what will feed that stylesheet. Hard returns and using the spacebar or tab to indent a paragraph will not translate well into ePub: be sure to use the paragraph style properties to do this. Creating headings ad hoc will lead to inconsistencies in detecting chapter breaks, and in the appearance of your work when you use an automatic converter. While you can manually repair this in something like Calibre, if you simply upload a Word file to any of the services offered by Kobo, Kindle, Smashwords, or IngramSpark, you won’t be able to fix it without uploading a new file (which may cost you a revision charge).

Addendum

Here’s the code I used for creating a frame to resize images to the device in ePub.

<div>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="100%" height="90%" viewBox="0 0 594 648" preserveAspectRatio="xMidYMid meet">
<image width="594" height="648" xlink:href="images/image5.png"/>
</svg>
</div>


Then make the dimensions in both the svg and image tags match the dimensions of your image, and the height percentage be a bit more than the height on a Kobo Touch (e.g. for its 600×800 screen, an image 648 pixels high would be 81%, so I put 90% to give it a bit of a whitespace border).

Of course, as time goes on you may start caring less about backwards compatibility: newer devices from Kobo, Sony, and Nook have higher resolution screens, and likely already outnumber the older devices. In the next few years you may want to use the same trick for resizing, but use a higher screen resolution for your base.