Peter Schaffter <pe...@schaffter.ca>:
> Ignorance about groff as a complete typesetting system is
> practically pandemic. After five editions, O'Reilly's _Running
> Linux_ still demonstrates groff usage with a tutorial on writing
> manpages. And recently, I came upon this parenthetical comment at
> the Simon Fraser University site:
>
> "(I have a weirdly retrotech idea that we could do typesetting with
> groff. For regular prose, groff is every bit as powerful as TeX,
> while being about one tenth the size and complexity.)"
>
> If groff is as powerful as TeX while being one tenth the size,
> why on earth does the author dismiss it out-of-hand as weirdly
> retrotech?
That's not a mystery to me. If it stays one to you, we have a problem;
you can't plan to do anything effective against that perception if
you don't understand it.
Here are several reasons groff gets written off as "weirdly retrotech":
* The [nt]roff markup design has a lot of tells that it was designed
for very old machines that were ridiculously underpowered even by the
standards of, oh, 1990, let alone today. Line-by-line formatting,
short request names, limited number of font positions, no color
support, a hole where embedded image support ought to be, things like
that. Don't counter that groff fixed some of these things; that would
be missing the point, which is that the core design screams "legacy!"
* Sheer calendar age - a lot of people not sophisticated enough to spot
those tells know it was written 40 years ago.
* Strange, irregular, archaic-seeming markup design compared to XML or
even TeX. Brian Kernignan called it "rebarbative" in *1979*.
* Weak support for HTML output, no support for ePub. People on this
list may think it's just fine that groff is so printer-oriented, but I
promise you nobody else who was out of diapers by 1996 shares *that*
quaint opinion.
To put it more directly, groff seems like retrotech because it *is*
retrotech. This creates a bit of a problem in trying to convince
anyone otherwise.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
