|Subject:||Re: [Groff] Why is it...|
|Date:||Sat, 5 Jan 2008 12:50:42 -0500|
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
|[Prev in Thread]||Current Thread||[Next in Thread]|