Home > Applications

Computerworld - After years of marginal acceptance, e-books have finally started to eclipse their printed-and-bound ancestors. Casual and sophisticated readers alike are growing much more accustomed to reading from a device -- an e-reader, a smartphone, a tablet or a laptop. They're also catching on for business and technical audiences -- for example, HR departments can distribute employee manuals digitally, while IT staffers can carry around 800-page reference manuals for their favorite programming languages or operating systems without having to dislocate a shoulder.

One of the most attractive features about this process is that you don't have to be a professional publisher to produce a useful and well-formatted e-book. Almost anyone can take an existing manuscript -- a technical manual, a corporate white paper or even a personal biography -- and turn it into an e-book.

But you need more than just your document. You also need the right software and the know-how -- because producing an e-book is a little more complicated than it ought to be. The breadth of e-book formats out there, and the quirks of converting your source document into one of those target formats, can make the conversion process anything but straightforward.

In the following article, I've attempted to unravel that particular knot by looking at the e-book creation process from beginning to end -- from formatting the source document to reading the finished product. I'll discuss what formats you need to start with and convert to, detail some of the issues you may encounter along the way, and suggest some software applications that can help.

E-book creation tips

Creating an e-book can be a rocky process, often with no preset path from the original document to the finished product. It's difficult to tell in advance what you might need to do, or not do, to make sure a given project renders correctly. However, before you begin the conversion process, there are ways to make things go more smoothly.

Start with the cleanest possible input document. There should be no stylization, formatting or elements present that you don't want in the final product. If something can't be supported in the destination format, it may well get stripped out automatically, but sometimes it might just be translated into something you don't want. You might have no choice but to clean up the original by hand, but it may well be possible to script the cleanup process, depending on what you're using to compose your originals.

Consider using HTML as an intermediate target format in all cases. Since the majority of e-book formats revolve around some variant of HTML, it might be a good idea to standardize on HTML as the format to export to first from whatever program you used to edit the document. This minimizes the amount of processing that has to be done by the e-book converter itself. What's more, if you need to perform any manual editing on the file to get it to process correctly, HTML is a convenient format to do that: You have direct access to the source code via nothing more than a plain-text editor.

Test the results on multiple devices. Get your hands on as many reading devices as possible -- or, failing that, get in touch with people who have a number of different reading devices and get feedback from them. The desktop Kindle application, for instance, has quirks that the actual device does not (e.g., how each handles non-Western characters), so it helps to know when problems like this are relevant.

Be prepared to repeat as necessary. You will almost certainly have to make multiple passes across an e-book to make sure everything translated correctly. Odds are it won't -- at least not the first time -- and you'll have to go back and tweak many different things by hand. In a way, this is another argument for using HTML as an intermediate format, because many of the tweaks that might need to be carried out could be partly automated. Keep notes of what breaks each time so you don't have to repeat your mistakes.