Publishers sometimes ask me, “What [ tool | filter | app ] should I use to save my [ Word | layout ] files to EPUB format?” And I have to be the bearer of disappointing news: it’s not that simple. EPUBs that are produced using the sorts of tools that offer a Save As… EPUB option are files that may validate (with a bit of luck), but no one will want to look at those ebooks, and you certainly wouldn’t want to offer them for sale.
Let’s back up for a minute. Why are we in this situation of wanting a somewhat mystical solution to producing ebook files? I say it’s because of two key publishing workflow needs that make the process more complicated than it might seem to non-publishers.
- Publishers need an authoring/editing system that is ubiquitous and easy to use, to give them the flexibility of working with many different authors and editors working on a variety of platforms. The collaborative nature of manuscript development requires review passes with visible, user-identifiable changes and comments, and the ability to accept or reject changes one-by-one. Most publishers use Microsoft Word to fill this role. Some publishers use Word in conjunction with file sharing applications that offer version control and collaboration features, but most simply email docs back and forth and rely on a human project manager to keep things straight.
- Publishers need sophisticated layout and paging controls (such as those provided in Adobe InDesign) to produce beautifully designed print books. Even for the driest of technical books, good design is essential for readability. Final edits and corrections are made in the layout files, which means that the layout files—and ultimately the PDF that gets sent to the printer—become the definitive work.
These two requirements have locked publishers into a workflow that has them building the print book first, and then creating the ebook from the print files. Creating an ebook from layout files can be partially automated to the degree that layout files are consistently structured (a tall order), but some amount of manual work is generally involved. It’s a time-consuming process frequently taking a minimum of one week, sometimes longer. And it’s not free. While the cost isn’t necessarily prohibitive for a single book, it adds up when applied to a publisher’s entire catalog. And finally, many publishers have learned the hard way that file conversions introduce the potential for errors. So they’ve had to build quality controls and checks into their process, costing more money and time.
The more intrepid publishers have taken the plunge into XML workflows, some (notably, O’Reilly) very successfully. But most publishers have shied away from costly XML systems because it just hasn’t been practical to find one that fully meets the two requirements outlined above, or at least without breaking the bank.
It almost goes without saying that any new solution must fill both of the requirements I keep talking about, and of course also output printer-ready PDF, bookmarked “uPDF”, EPUB, and MOBI. The good news for the would-be alchemists is that we seem to be on the brink of a solution.
Let’s tackle requirement #1: An authoring/editing tool that is ubiquitous yet offers the sophisticated collaboration and review controls. Well, what is more ubiquitous than a web browser? At Books In Browsers 2012, we saw demos of applications that hint at delivering this requirement through the browser: Adam Witwer of O’Reilly demoed Atlas, and Adam Hyde of booksprints.net and FLOSS Manuals demoed Booktype, which offers a SaaS model for customization. Maureen Evans and Blaine Cook demoed Poeti.ca, which offers browser-based, traditional-looking (only more beautiful) collaborative editing features that were a delight to behold.
Moving on to requirement #2: Controls for beautiful design. Adam Witwer showed us complex page layouts produced in Atlas, and my colleagues at Safari Books Online have been experimenting with pushing the boundaries of what Atlas and CSS can do, with exciting and encouraging results.
So… sure, the tools may be slightly immature at this moment, but they are under active development. It’s clear to me that we (and after a lifetime in publishing, I identify myself as a member of the publishing community) need to begin making the move to modern publishing. Why not get to know a developer working in this field and collaborate to build the exact tools you need? Why continue looking for the philosophers’ stone to turn one thing into another completely different thing, when you could produce your gold right from the start? The new world of publishing tools tantalize us with their shiny potential: to save money and save time, without sacrificing quality either at the press or in the e-reader.