Re: [Groff] Replacing groff with troff?

[Clarke Echols]

I was severely criticized in 1991-92 when I was responsible for the
HP-UX manpages because I was adding examples, splitting cp, ln, and
mv into three separate pages, and doing other things to cause the
total manpage files to expand to (gasp!) nearly 8 or 9 Mbytes and
we "needed" to keep disc consumption down.  It was so bad that I
had to carve the manpages into 50 filesets so people could load only
what they wanted or according to parts of the system that were
installed on their machine.

Never mind somebody might be developing software to run on a big server
and needed manpages for the libraries they were actually going to use...

In 1983, 1 Tbyte of HP disc drives would have cost $100,000,000 and
required over 1,500,000 watts of power.  Today you can buy 1 TB in
a small disk at a Big Box retail store for $100 and it runs on 10 watts.
And it's faster.

When I built the HP-UX 9.0 reference manual (3000 pages in 3 volumes),
I used a shell script to pull the correct version from the revision
control system, extract fileset info, links, table of contents, index,
and the delivery database entries for system integration deliveries of
manpage filesets.  It took about 25 minutes to build the entire thing,
run troff on it, and have typeset files ready to send to a laser
printer.  And that was using 30 Mhz processors, not 2.6 GHz dual- or
quad-core machines.

And the shell scripts I used, the macros I'd written, and everything
else would probably run without error and produce essentially identical
output in 2010 on an Ubuntu Linux box.

Try that with Microsoft stuff.  And people wonder why I'm not a fan of
wonderful, spectacular Word?  I don't like being given "permission" to
do certain things, instead of telling the computer to do what *I* want
*it* to do for *me*.

Methinks a lot of "corporate" decision makers don't live in the
real world.

But "progress" continues.  There was talk about docbook and XML before
I retired in 1999.  But in a WYSIWYG world, anything that looks like
plain ASCII text is from ancient days, I suppose.

But I still build XHTML and CSS with vim and I like it just fine, even
if it is a bit cumbersome at times.  But I can make really spiffy
looking whitepapers with groff...

CE

Larry Kollar wrote:
> Ralph Corderoy wrote:
>
> > Hi Charlie,
> >
> > > All they're doing is putting mdocml in base to handle manpages.
> >
> >     http://mdocml.bsd.lv/
> >
> >     DESCRIPTION
> >
> >     mdocml is a suite of tools compiling "-mdoc", the roff macro package
> >     of choice for BSD manual pages, and "-man", the predominant
> >     historical package for UNIX manuals. The mission of mdocml is to
> >     deprecate groff, the GNU roff implementation, for displaying -mdoc
> >     pages whilst providing token support for -man.
> >
> >     Why? groff amounts to over 5 MB of source code, most of which is C++
> >     and all of which is GPL. It runs slowly, produces uncertain output,
> >     and varies in operation from system to system. mdocml strives to fix
> >     this (respectively small, C, ISC-licensed, fast and regular).
> >
> > "uncertain output"?
>
> That's just one lump in a whole basket full of bizarre. The following is 
> really directed at the mdocml dude…
>
>  > over 5 MB of source code
>
> Um… there are these things called "hard drives" that you really need to 
> look into. Seriously, I compiled groff a while back on a 486-based Linux 
> box with a 110MB (that's MB, not GB) drive, which had about 80MB 
> available for the OS once the MS-DOG & swap partitions got their share. 
> And that was the full-zoot groff, not some "base environment."
>
>  > most of which is C++ and all of which is GPL
>
> I understand some folks are allergic to GPL, but I fail to see what the 
> problem is with C++. Yeah, it took a while to compile groff on that 486, 
> but it takes a while to do *anything* on a 486.
>
>  > It runs slowly
>
> And that statement pretty much casts everything else you say into 
> question. "Runs slowly" compared to what? I haven't found any 
> general-purpose formatter that even comes close to groff, speed-wise, 
> and don't get me started on GUI tools. Some Unix deployments had a 
> "catman" directory with pre-formatted (ASCII) manpages... but are there 
> really general-use systems out there these days that are so slow, even 
> the overhead for processing a manpage is too much to bear? Embedded 
> systems, sure, but who's reading manpages on them?
>
>  > produces uncertain output
>
> At this point, I'm convinced that the author has never used groff.
>
>  > varies in operation from system to system
>
> Really? I have my work environment set up on MacOSX, Linux, and a 
> Dozebox running Cygwin. Works exactly the same on each box. It's taking 
> a little work to get it going on GnuWin32, but that's because I have to 
> port the support scripts.
>
> Sorry about the rant, but I can't let this disinformation pass 
> unchallenged.
>
>     Larry