[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Eric Raymond on groff and TeX

From: Clarke Echols
Subject: Re: [Groff] Eric Raymond on groff and TeX
Date: Thu, 03 May 2012 17:13:04 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120412 Thunderbird/11.0.1

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 
it would be a very different beast than the troff we know...


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]