Book Production: Start to Finish, How It’s Done

blog2I spend a lot of time explaining to people what is happening with their ebooks and print on demand books–mostly why their Word docs don’t make much difference to me. So instead of repeating myself, I’ll just write this post and send them a link.

Caveat: This is how I do things, the workflow I’ve developed. Not every book producer or formatter does things the same way–or for the same reasons.


What I need from authors are their source file (Word doc or whatever word processor they use–doesn’t matter, I can handle just about anything*), their full-sized cover image (jpeg), and any images they want inserted. It’s better to NOT embed the images in the source document. Rather, send them as attachments, or if there are a lot then stick them in a zip folder and attach that. You can indicate image placement with a comment: [INSERT IMAGE dogandcat.jpg CAPTION Best friends for life.] It’s also best to send the complete document, including all front matter and back matter, in one file. That way nothing gets lost or misplaced (and I don’t get confused). Don’t bother inserting hyperlinks either. When you do that, I have to take the time to recover them. Best just to provide the url and place it next to the text you want linked. Example [LINK Crappy websites.]

* No pdf files unless you are paying me to recover the text. And that can be very expensive.

Should I “format” my Word doc?
Don’t bother. You’ll see why it’s a waste of time a little further down the post. What you should concentrate on is your text, making sure it is properly copy edited, proofed and as clean as you can make it. If you have specific design requirements, write me a note. [JAYE, I WANT THE CHAPTER HEADS IN SANS SERIF WITH A GRAY LINE UNDER IT] Best to just stick to a basic manuscript format.


I create a folder for the project, save the original document, then make a copy of it. I start a text file called “Notes”. I go through the copy, tagging chapter/section starts, section/scene breaks, and making notes of any special styling the book requires (quotes, poems, songs, lists, text messages, emails, letters, etc.). Here I record in my notes the front and back matter, number of chapters, sections, and anything else I need to know. Once the styling is tagged, I tag the special formatting such as italics and bolding. If the front and back matter were sent separately, I compile them into the main document.


Copy/paste the entire document into a text editor. Here’s where I do serious clean up. All tabs, extra spaces, and illegal characters have to be dealt with. Because I like my files tidy, I straighten up the italics and bolding, too. And because I am also a writer/editor, I go through and make sure any manuscript punctuation is turned into proper printer punctuation. Now the file is clean and ready to format.


I create a folder which contains all the sub folders I need along with base files for the opf (manifest) and toc.ncx (internal table of content and guide). Depending on what type of device the client uses, I will do either an EPUB version or a MOBI version first. Then I tackle the images. I size and insert the cover image, and any other image files the client provided. If the client wants custom graphics, I make those. Once the folder is set up and the images are in place, time to style the text.


I use css (cascading style sheets) and html to style the ebook in the text editor. By this point, I have a good idea about the tone of the book so I use that to come up with a “look” that fits the story and complements the cover. Once the book is styled, I split the book into smaller html files–one per chapter or section. Then I complete the opf file, making sure everything is in there, and finish the toc.ncx. The ebook is now ready to compile and convert. Once it’s converted into an EPUB file, I open it in an epub editor. I run quality checks to make sure everything is where it is supposed to be and I haven’t made any bonehead goofs. Any changes I make in the editor, I also make in the html files. Then I validate the file and if it’s for a MOBI/Kindle version, I convert it. Now it’s ready for proofreading.


If I am doing the proofreading, I load the ebook on my Kindle and go through it word by word. If I find a goof, I fix it in the original html file. If the client is doing their own proofreading, I encourage them to load the ebook on their device (or use a program such as the Kindle Previewer or Calibre) to see their book “live”. They can use a copy of their original document for mark up. All they have to do is highlight all changes. They can also leave me notes (highlight those, too!) if they want changes in the styling. The client sends the doc to me and I make the corrections/changes in the html files.


I send a copy of the final version to the client for a quality check. If everything is a go, I build the additional versions the client needs. I don’t hold with the notion of one-size-fits-all for ebooks, so I make separate EPUB and MOBI ebooks. Depending on the client’s distribution plan, I might make several retailer-specific versions (different hyperlinks, different promotional material, etc.). The ebook is done.


If the client needs a Word doc formatted for Smashwords and/or a print on demand book, I compile the clean/ proofread text into a new text file and remove all the html codes. Then I copy/paste that into a Word doc. If for Smashwords, I use a simple template. If for print on demand, it’s just a generic file that I will place into an InDesign document.

Notice what happened with that original Word (word processor) doc? Once it’s tagged, I have no more use for it. I might glance at it for reference if the styling is complicated and the client has specific needs, but except for its text, it has no role in the actual ebook build.


On the left is the Word doc that I have tagged; on the right is the html version. Same text, but notice how it doesn’t resemble the Word doc at all. :)

blog3Here is the same text looking like an ebook. Notice the lack of resemblance to either the original Word doc or the html file.

I know some of you have questions. I’ll try to answer.

What about the font?
If your ebook requires a special font, I’ll embed it. If not, I won’t declare a font at all and leave it up the ereading device and user to decide which font they want for their reading pleasure. You can make life easier for yourself by not worrying about fonts in your Word doc. Compose with whatever makes you happy. If you are using special characters such as letters with acute or grave marks, or foreign characters (Greek letters, for instance) I recommend sticking with Times New Roman. Its character subsets render properly (mostly) in ebooks. Other fonts and subsets can have serious translation problems.

What about margins and justification and and and…?
None of it matters. Think of your Word doc as a component and the only thing that matters is the text. Your ebook is not going to look like your Word doc. You don’t want it to look like your Word doc. Whatever formatting you do is going to be lost when I copy/paste the text into the text editor. As I said before, if you want something special, just write a note in the document and highlight it. I’ll find it.

Can I make changes myself in the finished ebook?
If you’re familiar with using an epub editor, sure. You can’t do anything with the MOBI version, but I can provide the pre-conversion epub file that you can tinker with and then convert. If you’re not handy with an epub editor, then contact me and I’ll make the changes for you. (I rarely charge for minor changes or cover updates.)

For the Do-it-yourselfers who are reading this, pay heed to the ongoing theme in this post. Clean text, clean text, clean text. Clean text (both in the writing and formatting) is what makes or breaks an ebook. Make sure it’s in tip-top shape going in, then proofread the actual ebook to catch any remaining goofs or formatting hiccups. (For those of you who are uploading Word docs to Amazon, you can proofread your Kindle ebook before you upload it for distribution. Download Mobipocket Creator then use it to convert your Word doc into a prc file. Then, convert that into a mobi file with the Kindle Previewer. You can either proof the book (both text and formatting) in the Previewer or load the mobi file onto your Kindle and proof it there.)

I’m sure I missed some questions. Feel free to ask away.

TWO Files For Smashwords?!? Not So Fast With The WTF, Folks

I’ve been one of the noisy gripers bitchin’ about the Smashwords “Meatgrinder.” My complaint was not what Mark Coker of SW was doing, but that MS Word makes lousy ebooks. Now, Coker has made it possible for ebook producers to submit validated EPUB files for distribution wherever fine EPUB-platform ebooks are sold.

This is terrific news.

Now I’m seeing complaints all over the ‘net that in order for an ebook to be fully distributed in the SW catalog one must also submit a Word file along with the EPUB file. A lot of WTF going on and people acting as if they’ve been somehow buffaloed.

Back off a minute and put down your pitchforks and torches. In order for SW to do what it’s been doing, it’s had to take a one-size-fits-all approach (could not have afforded it any other way). Using Word as the source file for conversion made sense for two reasons:

  • One) SW is mostly a self-publishing platform for WRITERS who use WORD PROCESSORS to create DOCUMENTS;
  • Two) Ebook files are based on html coding (they are essentially little websites) and most word processors are based on html which can be converted so they can be read on various and sundry devices.

The problems were not so much in the conversion. The problems came from the ereader devices. Every one of them is different. Some use older technology, some use the newest technology. Many have user interfaces, allowing readers to customize (to an extent) the way they read an ebook. (Ever wonder why mobi files are so big compared to an EPUB file? It’s because they are actually several different formats–eink, tablet, keyboard, touch screen–all of which display differently and give the reader different options on the various Kindle devices.)

Smashwords also offers readers different options, such as PDF and (essentially) text files for reading on the computer. They offer formats like LRF and PDB for people with older, almost obsolete devices.

A mobi file can be converted from EPUB, but it requires some adjustments to the css, the cover image and navigation coding. You can do things on a Nook you can’t do on a Kindle (for instance), and vice versa. Much different platforms. I can convert an EPUB to a mobi file and read it on my Kindle, but in order to make it work properly on all Kindle devices, in order to make it convert through Kindlegen without errors, I need a different type of EPUB file.

Then you get into the platforms that aren’t based on EPUB at all. Can I convert an EPUB file into a pdf file? Well, sure, but it’s ridiculously convoluted and requires more clean-up than conversion. The reason is in the name: “Portable Document Format.” Word files convert easily into pdf files because both of them are document files.

The beauty of what Smashwords has done is that if you have a validated EPUB file (and that means error free according to IDPF–International Digital Publishing Forum–standards) it is going to work on the various devices using the EPUB platform–namely Nook, Kobo and Apple products. It will work the way users (our customers) want them to work and the way the device makers intend them to work.

What it boils down to is quality control. I can control the quality of EPUB files in ways that are not possible with a Word file. It’s not about the bells and whistles, it’s about the formatting and making sure my ebooks are stable and functional across devices.

If you understand how ebooks work and how other file formats work, then you know it is not feasible for SW to convert EPUB files into other formats such as mobi or pdf or rtf. That’s my job. These are my ebooks and my readers/customers, and it’s up to me to figure out the best way to make the ebooks I create compatible with their devices.

There is no “one-size-fits-all” when it comes to ebooks and ereading devices. SW made a valiant effort when it tried to force Word into that role, but it was doomed from the get-go because Word is not the right tool.

EPUB is only one format out of many, and it is not Smashword’s or Mark Coker’s fault that the retailers and device makers cannot get their shit together and settle on a standard.

You do not have to submit two files to SW if you don’t want to. You can go EPUB only–which shuts out those who don’t have a device based on the EPUB platform. You can submit a Word file only–take your chances that your ebook is going to glitch, or settle for an ebook so generic it might as well be a text file.

Something else, too. Smashwords is a distributor. It reaches markets that indies cannot always reach on their own. I suspect the number one reason many of those avenues are closed to direct distribution from indies is because those outfits don’t want to deal with buggy, broken, half-assed ebook files created in word processors. SW could have insisted that those who wished to use their distribution service must provide files in compliance with the different platforms. That would have set back the ebook revolution several years. Instead SW came up with concept that mostly worked. So to those who are bitching that they now have to provide TWO files to SW, take a deep breath, step back and consider the alternative–the market could demand that you create up to ten different formats in order to reach all your potential readers. That, my friends, would be real cause for cries of WTF.