Re: [Groff] Eric Raymond on groff and TeX

[Clarke Echols]

On 05/03/2012 04:57 PM, Meg McRoberts wrote:
> Hi, Eric,
> Nice to know that you're still monitoring this list...
>
> I was involved in converting some documents from a home-grown
> version of eroff/mm to Docbook back before Eric's tools were available
> and I agree that there is a LOT more to it than just .EMPH.  For example,
> strings were identified as commands, files, structures, etc and then the
> style sheet defined whether they were bold, italics, monofont, etc.  And
> after living through a few episodes when the "style" people decided that
> commands should be italicized rather than bold, then a few years later, back
> to bold, then monofont, I can certainly see the advantage of that!
>
> The most challenging discipline when writing in Docbook was that each
> entity had a beginning AND AN END -- and you had to stick to the rules.
> No more nesting an H5 directly under an H2 just because you like the way
> it looked!
>
>
> I suppose it is theoretically possible to turn troff into a structured system 
> but
> it would be a very different beast than the troff we know...
>
>
> meg

That brings back memories of 1989 when I battled HP's Unix labs.  The 
HP-UX reference was called "the brick" due to size and density, and I
became known as "the bricktator" thanks to my monarchical management
style.  But I forced it through, and commands were in COURIER, not bold,
and variable arguments were italic.  I eliminated all \f... strings and
converted the entire mess to man macros.  It took about 10 minutes to do
after I spent 4 hours writing a shell script that ran vi 
non-interctively from a commands file, then sent the buffer through sed
to do what vi couldn't do.

The result was beautiful!

And my detractors were silenced. :-)  Including the ones who insisted
if a command name started a sentence, it had to have an initial cap, as
in "Cp copies files..." instead of "cp copies files..."  Or worse, they
wanted "The cp utility copies files..."

The problem is formal policies shouldn't over-rule good sense, however
uncommon it may be.

I know of no really practical methods of getting copy that looks good in
print, on screen (via nroff), AND online in XHTML, HTML, or whatever 
else is wanted.  And I'm not convinced obtaining such makes a lot of
sense.  Identify the audience, then deliver it in a way that is easy
to use, easy to read, with writing and layout that is easy to read
and understand.

Clarke