Re: [Groff] Why is it...

[Larry Kollar]

I've been watching & reading, waiting until I had a little time to  
say my piece....

Part of the issue is that *roff languished as a proprietary software  
package for far too long. The Free world developed several subsets,  
usually with -ms or -man (or some completely different thing) hard- 
coded. By the time James Clark wrote groff, the world had moved on:  
the academics to (La)TeX, 'most everyone else to WYSIWYG.

As it stands today, groff certainly has its shortcomings, but they  
can be overcome. These are the biggest ones in my opinion, and others  
may differ:

1) Ease of use. David Case mentioned LyX as a front-end for LaTeX,  
and I personally like LyX's UI better than any other graphical  
writing tool i've used, Free or proprietary. But LyX isn't tied  
solely to LaTeX -- it can work with DocBook as well, using importers  
or exporters. Groff could be made to work using the same scheme,  
although it would have to be limited to a particular macro package  
(or two).

2) Font technology. TrueType is do-able; Zvezdan showed the way a  
while back. OpenType might be more difficult, probably requiring some  
fixes to grops and some new requests/escapes to turn OT's knobs. I'd  
like to see a pre-grops go out and generate metrics on the fly,  
caching them for later use -- that would eliminate any issues with  
font installation. (Keep the old fonts for backward compatibility  
though.)

3) Lack of organized advocacy. Groff could easily handle many of the  
technical writing issues that people try to solve with XML, but it's  
been forgotten. IMO it's utterly silly to develop an XML-based "roach  
hotel" format like XSL:FO for formatting, when groff could do a  
better job with less effort. The Unix Text Processing book could help  
here, and I'll readily admit that life has forced me to drop that  
particular ball.

Notice that I didn't say anything about macro packages. That's  
because people tend to build custom systems to work with their  
documents. They do the same for XML-based systems; DITA (a topic- 
based doctype) is designed for "specialization" (as its fans call  
it). The -man package could be "specialized" in much the same way --  
usually, a gearhead or consultant handles the initial specialization  
& maintenance and the writers simply use what's given to them. The  
extensions I added to -man a while back, which allow more control  
over the layout, are an initial stab in that direction. Book-style  
documents can be done with -mm or (more commonly) a layer on top of -ms.

My two cents,

-- Larry