A few days ago, I hit the ‘save and publish’ button on the Kindle Direct Publishing (KDP) website to launch Mandated Memoranda Publishing’s second book: Tragic Wonders – Stories, Poems, and Essays to Ponder. I found one glaring (to me) error in a chapter title very late in the quality control process. I left it.

This post is an update to a previous article on self–publishing. Several things are new with Kindle Previewer software and my process.

The Kindle Previewer (KP) version I used is 2.92. KDP no longer provides an emulated means to check your Kindle files targeted to iPhone/iPad. It generates a file with extension .azk. You’re supposed to sideload it to your Apple device to test it. I have no Apple device.

Additionally, KP 2.92 generates a fault when it produces the .azk file. Windows captures the fault this way:

I sent a query to KDP about the fault and didn’t receive a reply once they figured I wasn’t asking for advice on my .azk file. This was a tad disturbing, to say the least. Then I went ahead and published Tragic Wonders. A friend with an iPhone purchased the book and said it worked fine. However, on 10 January 2014, I received a query from KDP about this issue. We’ll see if anything good results from the continued discussion.

Enough talk of Amazon’s problems. On to the new features of our process, some of which may be technical. We discovered and corrected some upsetting features imposed by Microsoft’s Notepad application. We used the text–align style attribute for chapter titles and table of contents (TOC) entries. We figured out some intricacies of nested .ncx file logical TOCs. We tried a different approach for page-breaks. Finally, we used Kindle Previewer to generate our last few .mobi files that we submitted to Amazon KDP.

We discovered through some disturbing errors in our .mobi files that Notepad was inserting non–printing characters. How could we tell if they were non–printing? It showed up in truncated logical TOC entries (generated by Kindlegen from .ncx entries) during the QA review. It also showed up in HTML TOC errors in the .mobi file text. Both errors occurred at the point where the lines in the files (.ncx and .htm) word wrapped.

It turns out this is well documented and has been an issue since Notepad first appeared. A workaround is: don’t narrow the Notepad application window so any TOC or logical TOC text word wraps. If you’ve done so and you have funny truncation error then you can retype those entries like I did (very tedious). A solution may be to use Notepad++ (but I haven’t, yet).

We used the text–align attribute to left justify chapter titles and TOC style entries. Amazon’s Kindle Publishing Guidelines only discourage specifying alignment for body text so it reflows freely.

We figured out some intricacies of nested .ncx file logical TOCs (and didn’t figure out other things). This is  genericized excerpt from our .ncx file:

I call your attention to the em space setting off Story Title 1 as an indent. This conveniently differentiated story titles from section titles. Turns out there is another way, but not all eBook distributors use that method.

Having had difficulty with page breaks in our first book Tiānmìng – Mandate of Heaven, we tried a different approach to page-breaks this time. Using <br> without <p> or other formatting to end chapters seems to work. This is an example of what we did:

We discovered that KDP was using a file structure to read and assemble their .mobi file (the one you can download from them) after you submit your files to KDP. I remember reading about that somewhere in the literature but now I had a concrete example in the zipped HTML files KDP produced for download. I recommend you use those HTML files for further development once most of your bugs are shaken out (i.e., after final edits are long done and most formatting issues have been retired).

You’ll need to package your files into separate folders labeled: image, xml, and html. The image folder contains your image files. The html folder contains your .htm file (if you use one .htm file like I have, up to now). And the xml folder contains your .ncx file. The .opf file should reside with these folders either on the desktop or in your working folder. The files that come from KDP expect this structure (you can see the changes from your original files in the downloaded ones when you compare them).

We used the HTML files KDP generated to finish our development after we went a few rounds with Amazon KDP’s Kindlegen to shake out bugs. This led us to use Kindle Previewer on our .opf file to produce a .mobi file. Kindle Previewer invokes Kindlegen and even produces the verbose error report we use to validate our .mobi files. We submitted the resulting .mobi file to KDP and did final quality assurance (QA) testing with the .mobi KDP produced from our submittal. I plan on structuring my files using this new approach in future books.

After I completed my book, I happened on these two eBooks on Kindle formatting and process. The first, The eBook Design and Development Guide [Kindle Edition], by Paul Salvette (Author), emphasizes formatting using cascading style sheets (CSS). It does a masterful job of explaining in simple terms how to use them. The process that is described bypasses the MS Word to filtered webpage step by copying and pasting the original manuscript into a text file and proceeding from there. I think this approach avoids some errors while enabling others.

The second book, EBook Formatting: KF8, Mobi & EPUB [Kindle Edition] by Matt Harrison (Author, Illustrator), says it is purely concerned with formatting. Heavily programming oriented, I expect it will provide clues for me to format my next book more professionally.

I’m not sure why Amazon’s KDP Systems Architect or chief designers can’t put out a series of books on Kindle book development akin to Microsoft’s series. I’d be first in line to buy the reference (if it’s $9.99 or less, of course).