Publication of Thursday’s Lotus as an e-book: finding a suitable approach

Thursday’s Lotus is now available as an e-book through Kindle Store and Kobo, with others to follow. I’m glad I made the effort and hope this post will encourage other newcomers to explore further some of the options to contribute to the world of electronic publishing.

As someone whose career has been largely in technology, I found the preparation and publication of a hardcopy book a fascinating process, resulting in the very satisfying experience of holding a physical copy in my hands. But, of course, nowadays it’s expected that books be made available in digital formats for reading on handheld devices, i.e. as e-books. As I had other work commitments I concentrated initially on the paperback, making it as polished as I could; I felt pursuing an electronic version in parallel would have negated against that, so I put that thought to one side and merely indicated that I expected an e-book version to emerge in 6-12 months. Then, after a little break, I decided to start focusing on the e-book version in August and I published it in September.

For those who have already self-published a paperback, I’ll share a few general observations, but my thoughts are mainly for those who are interested in do-it-yourself (DIY) and have some experience of creating Web pages. It actually took me quite a bit longer than I had anticipated largely because I chose to pursue the DIY route and along the way I wrote some software to do some ‘heavy lifting’, but I found this rewarding and it means I can now help other authors produce both hard copy and electronic copy.

Just as Amazon’s CreateSpace offers a dedicated service for publishing paperbacks, Kindle Direct Publishing (KDP) is the analogue for e-books, and unsurprisingly CreateSpace points to KDP, easing the transition by offering to share the front cover and metadata. So, yes, it seemed a natural next step. However, one of the first tasks was to understand what exactly I was meant to be preparing for it wasn’t immediately obvious. After some searching, I learnt about an open technical standard called EPUB, the work of the International Digital Publishing Forum, a trade and standards association for the digital publishing industry. It consists of a markup specification, where document content is specified as (X)HTML, so it’s like preparing a special class of Web pages. Then there’s the specification of how everything should be packaged, table of contents, navigation etc., which is in a series of XML files. These files get bundled in a ZIP and renamed with .epub extension, and voilà! You have an EPUB instance, or ePub file. Just as there are a range of authoring tools for Web development in general, so there are various options for producing EPUB.

All well and good, except the list of members, doesn’t appear to include Amazon. Indeed Amazon has its own proprietary formats, Mobipocket (abbreviated .mobi) and Kindle Format 8 (.kf8). However, Amazon is pragmatic, and its KDP service supports uploads in various formats, including MS Word, HTML, ePub, MOBI and so on. Nevertheless, expectations need to be tempered as the range of options hides the fact that for all but a simple text document, without revision of that document, these options will produce results that vary a great deal in quality. In almost all cases the original manuscript, typically authored in Word, will need to be carefully edited to ensure tidy and consistent formatting.

Plenty of pointers are available; Amazon provides a Simplified Formatting Guide and in the beginning I found it instructive to experiment with a transitional version, applying one of the freely available Word templates designed for Kindles. If I had been in a hurry, then I might have followed this path, but for a quite complex book layout, I was not confident that I could have sufficient control over the final output.

Irrespective of the method eventually chosen, I recommend becoming familiar with how KDP processes and prepares a file (.mobi, that actually includes the .kf8 version as well) that it would use as a publication candidate. Within the KDP dashboard, you can preview the result online using the Web-based previewer and download the file to inspect on your device (just use Send to Kindle). When I tried this, downloading the first drafts for viewing on my Kindle e-reader (7th generation) all the words were still there and I was impressed to see that the endnotes (which I had arranged on a per-chapter basis) had been converted to footnotes with working hyperlinks between text and notes.

Beyond this was not so good — it had numerous issues:

• table of contents, list of figures etc had ragged layouts
• in fact, generally the layout was all over the place, with chapter headings not properly aligned
• the images had become small and were variously centred or left-aligned
• varied font sizes
• large gaps in text
• no logical table of contents (i.e. the one available via an e-reader menu item)
• the index, which had originally been designed for a fixed layout, was replicated and in its static form with reference to hardcopy page numbers made little sense

In pondering these issues I learnt quite a lot about going from fixed layouts to reflowable layouts. I pondered quite a lot the last one in particular and eventually realised that there might be a path to a meaningful solution. I had originally created an index the traditional way and been faced with the traditional problem afterwards: on completion of a draft I had worked my way through the book to laboriously compile the index, but subsequently needed to revise it quite considerably. I then discovered the method of indexing in Word using bookmarks as the targets of index entries and the (not particularly robust) Dexter add-in, for managing these entries and generating automatically the index from the bookmarks. Thanks to Robert Papini, the index was re-made this way, to keep evolving without great effort. Furthermore, for the e-book I used another tool from the makers of Dexter, IndexLinker, which turned the index into a set of hyperlinks to the respective bookmarks. Saving this as (filtered) HTML preserves the links and this has been successfully carried over to the e-books.

Much as I could solve some particular problems, tweaking the Word document and uploading would not be completely satisfactory, so I focused attention on the EPUB format, reassured by various messages in fora that Amazon has invested considerable effort in converting to .mobi/.kf8 At this stage, I had to decide how far I wanted to proceed (really how fussy I was to be about the final rendering). For many, particularly those who don’t want to immerse themselves in the technicalities of HTML and XML, there are authoring environments that facilitate the process and can produce good results. Probably the most popular of these is Calibre, which is a whole environment for production and management of e-books.

I gave it a quick go and it could correctly display chapter headings, with the lotus image properly aligned, but inevitably it reflected the quirks in the original and some issues would have to be corrected in the in-built editor. At this point you are exposed to editing HTML and CSS, and whilst the import of a Word document does a lot of tidying (and smartly splits a large file into smaller files based on sections), it does retain much of Word’s original markup and superfluous spacing; also in the translation, it adds a lot of its own CSS without using semantic labels.

As I wanted to learn more about EPUB and edit/process HTML and CSS, I opted to leave Calibre for another day and use tools and techniques with which I’m familiar. I’ll describe some of these in my next post …