First off is my toolset:
iWork Pages - Can read most MS Word files and write RTF files
OpenOffice Writer - Free program that can read most MS Word files
Calibre - Free program that can translates Kindle e-Books to EPUB e-books (and supports hundreds of other conversions)
Gimp - Free photoshop-like program for touching up, resizing and rescaling cover and interior illustrations.
MAC OS X utilities - Including Perl (for fixing foreign characters), Xcode (for editing HTML), textutil (for converting RTF to HTML)
Kindlegen - Free program from Amazon that creates MOBI files for the Kindle
Kindle Previewer - Free program from Amazon for proofing the final product
iPad - I use the Kindle App and the iBooks App to proofread the Kindle and EPUB books that I create.
Firefox - Any web browser would do. I use this to proof the HTML files that I create.
Second is my process:
1. I solicit files from the author and ask about design choices and details that will be encoded into the final product. Among these are:
- searchable keywords,
- the genre (called the BISAC code),
- retail price,
- ISBN (optional),
- projected pub date,
- name of publisher,
- name of author or pen name as it should appear on the book,
- which chapter or section should be the "home" page where it opens on first read,
- order of the sections and which should appear in the Table of Contents,
- etc.
2. I download and verify the files that the author sends via email. This usually means a Word document, a jpeg or png file for the cover, and maybe some illustrations. I don't own a copy of MS Word, so the file must be readable in iWork Pages or Open Office. Most files translate well.
Amazon recommends that cover images be at least 1000 pixels high and that the aspect ratio be 1 to 1.6. It used to be smaller, but the Kindle Fire is taller than the older readers. The author may have their own artist resize the images. If not, I am adept with Gimp. (Did I mention that I pursued a Minor in Visual Arts in college?)
One of the most important by-products of this conversion process is a clean HTML file. All major E-book formats require HTML files as inputs to the final process that leads to their special file format, so creating a good HTML version helps us no matter what our target reader may be.
3. Convert the text of the book from Word to Pages (using iWork Pages). All this requires is opening the document in Pages and saving it to a new name. I always leave the original files untouched for later reference in case I goofed things up.
4. Convert from Pages to RTF (using Pages). To do this, I use the Export command. Why don't I export straight to HTML, which is one of the options? Or even EPUB? Then I would be finished! Sadly, the results of that approach are not pretty. (MS Office can also save as HTML, but the styling it generates is so complicated that you have to rip most of it out, which takes DAYS of effort.)
5. Convert from RTF to bare-bones HTML (using textutil). Here is an example of how I use this free tool that comes standard on MACs:
textutil -convert html -output book.html -excludedelements "(span,font)" -title title -author "authors name" -keywords "words" -subject subject "The Emerald Skull - converted.rtf"
The crucial thing is that it ditches almost all the formatting except the bold, italics, underline and paragraph tags. I will have to add those things back myself, but the end result will look much better than letting the word processor handle it. Word processors (like Word) that save files in HTML format make use of features that are not supported on the Kindle, so they have to go.
6. Turn foreign characters, smart quotes, etc. into HTML entities. Any character in the manuscript that is not a normal English letter or punctuation mark it needs special treatment. For example, that fancy double quote (the smart quote) that Word creates when you begin a quoted passage in place of the straight vertical double quote mark from the old typewriter must be changed into an HTML entity as <ampersand>ldquo<semicolon>. Here is the perl script I use to fix most of these problems:
perl -MHTML::Entities -MEncode -p -i.bak -e '$_=Encode::decode_utf8($_) unless Encode::is_utf8($_); $_=HTML::Entities::encode_entities($_,"^\n\x20-\x25\x27-\x7e");' book.html
(It relies upon a few common Perl packages that you may need to install.)
7. Decide on section names and order, and identify the start page. This is vital, because the table of contents is the scaffolding for the whole book.
8. Generate a skeleton HTML document with a TOC, section headers and basic CSS stylesheet.
This step used to take me days. It is tedious, involves lots of hyperlinks and repetitive HTML boilerplate. And it is dependent upon whether the TOC is one level, two levels, or even three levels deep. Are chapters numbered or named or both? Are there multiple "parts"? How much spacing should there be between headers and body of chapters? To address this tedium, I wrote a program in C# (called Toccata) which generates the skeleton HTML file with table of contents and stubs for all the chapters, the OPF file (open packaging framework file with all the metadata that is needed by Kindlegen), and the NCX file (navigational control XML file).
The Toccata tool supplies a default CSS stylesheet that it has taken me years to perfect. It has styles for dealing with several kinds of quotes, poetry and its peculiar indents, scene dividers, initial large capitals, and many other small styling issues. I consult with the author to adapt it to their needs.
9. Copy and Paste from Entity-fixed
HTML (from step 6) into TOC skeleton (from step 8).
This is where I copy and paste each individual chapter into its place in the skeleton file. I give each chapter a once over to spot odd formatting issues as I paste in the text. I set the style of the first paragraph of each chapter to be distinct from the other paragraphs. (Many authors prefer the first paragraph to be flush left, and the remaining paragraphs to be indented on the first line.) I also set the style of the first letter (or two, if in quotes) to be a large capital. (If the author does not like large initial capitals, all I have to do is make one change to the stylesheet. Taking the feature out is much easier than putting it in later.)
At this time, I fix scene dividers to look uniform, replace triple dots with hellip entities (horizontal ellipses) and remove superfluous blank rows that the earlier steps in the conversion process often insert.
10. Format Front matter/end
matter. The title page, copyright page, acknowledgments, dedication, About the Author, and related pages often look the same from book to book. I start with examples from other books I have converted and make changes as needed. Many books have maps. I add a hyperlink to the image at this point.
11. Review chapter formatting. I compare each chapter to the originals and make sure I didn't botch the margins, initial caps, scene dividers, and specially formatted paragraphs, like personal letters, quotes, newspaper articles, etc.
12. Code all internal hyperlinks. Sometimes I have to write small programs to help with this. When I converted The Endless Hunt, I added a scripture index to the end of the book. My book included hundreds of bible quotes! The program parsed the file and found most of them and generated the index. I found the few it missed and added them by hand. Adding all those HTML links by hand would have taken me a week without the program.
For one author, I wrote a program to generate the glossary and include a hyperlink from the first usage in the text to the glossary and vice versa.
13. Compare all pages in Word doc to
HTML WIP, looking for formatting mistakes, especially loss of italics, bold, spacing. To review the HTML file, I open it in a Web Browser, like Firefox or Safari. This allows me to check the hyperlinks, look for misspellings, bad spacing, wrong font size, etc.
14. The author often does not have all the information I need up front. At this point I get from them any metadata that I am still missing, such as search keywords, price, release date, genre, etc. Then I edit the OPF file which Toccata created to hold the metadata
15. Convert HTML to Kindle format. Hooray! This is when I start to get excited.
~/Kindlegen/kindlegen Bookname.opf -c2 -verbose
Kindlegen is Amazon's tool for packaging the HTML file together with the metadata, images and navigational data (NCX file). It creates a .MOBI file. I use the verbose flag and watch for warnings. If a hyperlink is broken or malformed, it will let me know. The -c2 switch compresses the file more.
16. Review Kindle format, fix problems. I do three things to review the Kindle book:
- Open the MOBI file in the Mac Kindle Viewer.
- Open in the Mac Kindle Previewer
- Copy to Dropbox and open on my iPad in the Kindle App.
Each program works slightly differntly and allows me to find different problems. The Kindle Previewer allows me to simulate the Kindle 5-way toggle that readers can use to skip chapters on a real Kindle. This chapter skipping feature is often not implemented by people in a hurry to release an ebook. It is essential. The iPad allows me to check how images look in color.
I check all TOC hyperlinks, and end note links, and look for foreign characters that did not translate correctly. I change the size of the text to larger and smaller sizes. MANY EBOOK PRODUCERS FORGET TO DO THIS!!! Poetry, quotes and specially formatted and indented text look TERRIBLE at large font sizes if you do not plan for that. That is why I break poetry lines into smaller chunks than you might at first think necessary. (I need reading glasses, so I am very particlar.)
17. Send Kindle version to author for review. In a compressed schedule, I will also create the EPUB version to send.
18. Receive final cover art, author's feedback. Resize art as necessary. (Amazon has file size limits. It may be necessary to sacrifice a little image quality and compress the jpeg file more.)
19. Incorporate final cover, change text according to author's feedback
20. Convert to EPUB. I use the marvelous program Calibre to accomplish this. The tool has many subtleties, including some use of XML Xpath expressions for recognizing TOC structure and page breaks, which are not intuitive.
21. Review EPUB, fix problems. For this, I use Dropbox (or email) to send the file to my iPad. I preview it in iBooks.
I have had problems deleting old versions of a book so I can review new edits. To replace an earlier version of a book cleanly, follow these steps:
- On Mac (or PC), copy new file to Dropbox (or other file sharing tool, or email)
- On iPad, in iBooks, delete the old copy.
- On iPad, in Dropbox, select a different document (any document other than the book)
- On iPad, in Dropbox, select the new version of the book
- On iPad, in Dropbox, choose option to open in iBooks
- On iPad, View in iBooks
The third step above IS CRUCIAL. If you do not choose a different doc, the new version will appear to download, but it will still be the old version that gets sent to iBooks!!! Very confusing.
After this, there will be typos to fix, formatting issues to handle, but the work is mostly done.
Hooray!
Every book is different, and I vary the procedure to suit. For a long, sixty chapter novel, it took me ten to twelve hours over two days to run through all these steps. There will be more hours of corrections to make, but that gives you an idea of how much effort is involved.
Nonfiction books with subsections and multi-level tables of contents are particularly time consuming.
You can do it yourself. I just told you how. But wouldn't you rather pay me?
(PS. I strongly recommend Joshua Tallent's excellent books and website. I learned a lot about the process from his writing. Visit him at http://kindleformatting.com/)
