When I was preparing Speak for the Dead for publishing, there was no question that I wanted to make it available as an eBook. Unfortunately, my desire to do so wasn’t one of the things I considered when I formatting the manuscript for print.

Having the freedom & the skill to do so, I decided that I wanted to make the interior of Speak for the Dead a little more interesting than “1. Chapter text goes here”. If you’ve read the book or the free preview, you will have seen this:

All of the chapter headings in Speak for the Dead are done in this style, & I think it looks pretty darn fancy pants. But, when it came time to convert my print-formatted manuscript for digital delivery, things started going wonky.

I know half a smattering of html, & I don’t really understand how it works, I’m a bit like a dancing bear in that respect. I can do some basic markup, but I don’t really have that connection to why it works, only that it does. No more than a dancing bear knows why standing up on his hind legs earns him a treat, but so long as the fish keeps coming, he’ll keep dancing.

Perhaps if the initial conversion had gone as planned, none of this would have ended up this way, but the matter of the fact remained that, no matter what conversion tool I used, my eBook was formatted completely in bold type & I had no idea why. Because of the images I’d used (18, in a book with 14 chapters), I didn’t want to put my book through a meat-grinder-type process (Smashwords accept MS Word uploads, but then proceed to ruthlessly strip the formatting out – I wanted more control than that). I had a look on Google for answers & mention of the CSS came up – I knew what they were, so I tried following the instructions to unzipping my converted ePub & opening the CSS.

Turns out that the CSS generated by Calibre is a dystopian nightmare of redundant styles with incomprehensible names. I wasn’t going to find my answer there. I tried looking at the xhtml files that should have formed the body of my work & they were just as bad. More fool me for thinking that the “filtered” html option in MS Word might cut back some of the ridiculous tag-bloat that program suffers.

I decided to try use an eBook-building program, but all of them expected me to know things about eBooks that I didn’t. In the end, I managed to work out that they wanted the chapter files – the xhtml ones – but when I ran the program, something failed & the ePub it produced wasn’t even machine-readable.

Tip for software developers: there’s a market out there for a rich-text ePub builder. People could copy-paste their manuscripts, one chapter at a time, into a WYSIWYG editor while the software creates xhtml files and constructs the manifest & spine. You could have a tool that people can point-and-click to insert bookmarks while the program auto-generated a table of contents.

I already knew I didn’t want DRM on my eBook. While I’m not averse to the idea of DRM, & having not ever really given proper & deep thought to the questions of piracy, intellectual property, & the implications – a discussion for another time I’m sure – I’m am against the idea of making it difficult, or impossible, for people to legally manipulate their own files, that they paid money for. I wanted people to freely be able to download, backup, and transfer my book to their other devices. I want it to be easy for people to enjoy my book, I’m not about to make things more difficult.

With that in mind & my frustration at my inability to convert a product that was even remotely serviceable – I sat down at 9am on Sunday morning & began the formatting conversions I needed to make before converting to ePub, it was 2am on Monday morning when I finally packed it in – I decided: stuff it, let’s tear the whole damn thing down & build it over from scratch.

One of the leading complaints I hear from people struggling to convert their own eBooks is “I don’t want to learn any html”. Perhaps I’m biased, because I think this is a silly position. Not only is it easy to learn enough html to fake it, but the very discussion board they’re complaining on only offers the choice of rich-text or html formatting – the latter of which you need to use if you want to be able to insert images or a signature.

This is the tutorial I used to build Speak for the Dead as an ePub, though I did find it to be written at a level slightly above my paygrade. However, I’ve been using basic html in my blog posts for years, so the only new skills I needed to pick up was creating a CSS & packing a zip file.

Oh yeah, an ePub is just a renamed zip file. All you need to do is change the extension to .zip & you can un(de?)compress the whole thing with your pet archive program. That is, actually… stupidly simple.

Years ago (I don’t know if you still can) you used to be able to download the CSS for several of the WordPress blog themes. I had downloaded the theme I was using at the time & a tutorial on CSS, thinking I would learn me how to write a CSS so I could customise my blog’s layout. That turned out to be biting off more than I could chew, & that scared me off CSS for a long time. That being said, the CSS for an eBook is much, much, much simpler than one for an entire webpage – there’s just so much you don’t have to account for when laying out an eBook.

After trying (& unsurprisingly failing) to edit the CSS the Calibre conversion had given me, I decided to delete the CSS & make my own. I used this blog post as my basis, gleaning additional parts from random sources that I searched for on Google as needed. The CSS for Speak for the Dead is even simpler than the one demonstrated on that site, I cared nothing for the font that people read in, and during the print layout I’d limited myself to: one font across the board, two heading styles, and one sub-heading. Striving for consistency across a novel that had no need for things like block quotes and style levels had served me well when it came time to create my CSS.

If you’re curious, scroll to the end for the CSS I used.

I tried using the pcf file from one of the conversions & I’m not sure if I was screwing up the changes I needed to make, or if they were already faulty, but again I found myself starting with a blank document & typing out the manifest, spine, & guide painstakingly by hand. If you’ve never unzipped an ePub to look inside, the pcf is the file that tells your eReader how to use the rest of the files. A manifest is a list of all the files that should be contained in the ePub, while the spine designates what files to display in what order (for example, all of the image files must be shown in the manifest, but they aren’t part of the spine because they are displayed within the chapter files, not separately).

Regardless of all the difficulties I’d had using Calibre up until this point, I think the most frustrating was this: when I’d completed the pcf (and ncx & everything else) & formed it all into the ePub, Calibre imported it & displayed it perfectly well. Why is that a problem? Because my ePub wouldn’t validate.

Here is a fantastic online validator for ePub files. 99% of the errors that the validator ended up throwing were caused by typos, not any actual error in the files, or the way I’d assembled them. The remaining errors were stupid things like a file with a .png extension that I’d mistakenly copy-pasta’d in the manifest file type as a jpeg; or the fact that you have to put “jpeg” in the manifest, not “jpg”; or the file with the extension .PNG which was not a sufficient match to the manifest where I’d listed it as .png; or that the ncx refused to validate unless I used a more compressed layout, instead of putting everything on a new line – man, that one was annoying.

When I finally weeded out all the errors, it was almost weird that the file validated, there had been so many tiny, niggling things. But there was a lot of satisfaction in having the ePub ready. More than knowing that I’d overcome whatever problem was causing the conversion to fail, more than having a hand-crafted product, more than the fact that it looked exactly the way I had made it – there was satisfaction in knowing that I had stripped every last skerrick of erroneous html out of it. I’d taken my document from a bloated MS Word nested tag nightmare to something that used pure paragraph tags that only needed attributes on the first paragraph (no indent) or the scene breaks (to centre & space correctly). I guess I’m still old school, that I care about how clean my html is.

Speak for the Dead eBook CSS:

body {margin-left:1em; margin-right:1em; }
p {text-indent:2em; font-size:100%; line-height:120%; text-align:justify; text-align-last:left; margin-top:0; margin-bottom:0; }
a {color:blue; text-decoration:underline; }
.first {text-indent:0; }
.centre {text-indent:0; text-align:center; }
.break {text-indent:0; text-align:center; margin-top:1em; margin-bottom:1em; }
.i {font-style:italic; }
.title {text-indent:0; font-size:2em; text-align:center; margin-top:1em; margin-bottom:1em; }
.by {text-indent:0; font-size:1.5em; text-align:center; margin-top:1em; margin-bottom:1em; }
.head {text-indent:0; font-size:1.5em; text-align:center; text-transform:uppercase; margin-top:1em; margin-bottom:1em; }
.image {display:block; margin-left:auto; margin-right:auto; margin-top:1em; margin-bottom:1em; }

If you’re going to critique my CSS, please be gentle, it’s my first time.