Re: [Groff] Groff and computer education

[Larry Kollar]

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