I can’t tell you how much of a bother it’s been to get Scandals properly into different formats, such as ePub, HTML and PDF. Imagine having to worry about corrections as they’ll show up in half a dozen or so formats, each with its own rude surprises. Even now the job still isn’t done. Tech complexities are no small reason why we call the existing files “advance promo copies.”
Today’s e-publishing tools, including pricey ones selling for hundreds of dollars, just don’t work that well or fail to include enough capabilities.
Oh how Lida and colleagues must hate the hassles of dealing with Word and RTF files so that paragraph breaks show up in the right places. And then there are other joys—sarcasm alert!—such as distinguishing between neutral quotes and the directional variety. Lida and colleagues are not at fault. It’s the damn technology, which is still far, far more difficult and time-consuming to use than it should be.
A challenge to the open source community
With the above in mind, I wonder if the time hasn’t come for the OpenOffice crowd or others in the open source community to consider designing a multilingual program from scratch for ePub creation and other publishing activities. The OpenDocument format has its purposes, but book publishing shouldn’t be regarded as a major one.
ePubWriter, as I’ll call the proposed app, would offer all the capabilities of Writer but also output smoothly into ePub and HTML and, for printers, PDF. Ideally ePubWriter could even help deal with the inherent conflict between ePub (reflowable) and PDF (nonreflowable). Let there be an easy way to see exactly what the finished p-book will look even if the ePub version will be reflowable. And let writers be able to tweak to their heart’s content while seeing the final results of their changes.
Avoiding cognitive overload
Yes, yes, yes, I like the semantic approach, but it adds to the complexities of doing WYSIWYG—the very stuff so dear to most publishers and writers. The best systems might ask users to set defaults to cover many situations; perhaps there could even be standard choices to cover common structures and meanings found in novels and all that. I don’t know. I just know that the more effort writers put into quasi-programming, the worse their prose is likely to be. Talk about cognitive overload! It’s a problem for writers, too, not just readers.
I find it disconcerting that so many brilliant technical people lack empathy with writers and other civilians and create programs for themselves rather than the world at large. Ideally ePubWriter would be different and would be coded with lots and lots of participation from small publishers—ordinary publishers, not simply the technically inclined ones.
OpenOffice.org is strapped for resources. But maybe, along with the small publishers whom the OpenOffice people would be be helping, literary houses included, the group can make a pitch to the MacArthur Foundation, the Mellon Foundation or similar organizations.
MacArthur, meanwhile, just may want reconsider its strategy and focus on ePub-related efforts; that is the agreed-on standard of publishers. Sophie, which received a million from MacArthur, in addition to Mellon money, has been extraordinarily valuable as a way to demonstrate such capabilities as shared annotations, but now it’s time for the nonprofit world to bring these concepts to mainstream publishing. Such efforts could prove helpful not just to small presses here in the States, but also in developing countries, where the Net could revolutionize publishing and library use in places where existing resources are sparse or nonexistent. That means powerful, well-integrated programs that publishers can use for content creation for both E and P.
Don’t force writers and small publishers like Lida—wherever they are on the planet—to adjust to technology. Let the tech do the bending.