Peter Schaffter wrote: > It does no good to emphasize the universal portability of groff > documents, for reasons I know too well: if the publisher I send > a work of fiction to is a Wordie--they all are--I have no choice > but to provide them with MSWord documents.
Not that traditional publishers are doing all that well these days. Amazon's eating their lunch on both fronts of a two-front conflict: 1) They heavily discount paper books, creating an expectation of lower prices elsewhere. 2) By opening up the Kindle Store to anyone who wants to publish something, they've made the gatekeepers obsolete. Note that Barnes&Noble's Nook Store and Apple's iBookstore also participate in #2, among others. The two major eBook formats — MOBI (Kindle) and ePUB (everyone else) — are both Zip archives containing HTML, graphics, CSS style sheets, and control files. The latter contain metadata and sequencing information. So anyone who wants to publish an eBook simply has to crank out clean HTML. An open-source eBook library manager called Calibre (calibre-ebook.com) can generate eBooks from that, or you can build the control files yourself using a script. Now it's not easy to get clean HTML from *every* groff source, but if you use the -mwww macros and assume a typical fiction manuscript? It's not that hard, especially if you pipe the results through Tidy and use a hand-crafted CSS. I got close to decent results with an 800-page technical document I maintain at work, and it's tons more complex than a novel. Novels tend to not have huge graphics (beyond the cover art) or complex tables. Therefore, one who wants to write a novel using groff can do it, then upload the results onto the major eBook sites and bypass the Wordie publishers. > Let's > face it: filtering a groff document through sed or awk so it > becomes acceptable rtf, readable by MSWord, is not for the > inexperienced. Lucky those who are in academic publishing, where > *nix is entrenched. In my experience, and I've had to do this, it's easier to produce an HTML file and load that into Word (or better, OpenOffice, and save to Word… it's a little cleaner). My lament is: at work, all the writers in the company are moving to Author-It. It's a database system, and of course the client is Doze-only. I told my boss to expect my productivity to crater, and I wasn't joking. My 800-page manual takes about 4 minutes to typeset to PDF in groff (2-pass using pdfmark for internal hyperlinks), and 45 minutes to 2:30 in Author-It. Like with groff, you might have to tweak a few things (usually pagination) and re-publish… which can be rather painful. And like BDSM markup languages, there are no keeps or .ne equivalents that make pagination less of an issue to begin with. For most of what Author-It does, we could have done it a lot cheaper and with much higher performance by deploying a CVS server on the network and using groff. With some extra programming help, we could have had HTMLhelp output too, probably a lot more easily than consultants could fix our publishing templates. But… Command line! Tags! Icky! -- Larry