Re: [Groff] surprise, surprise

[Clarke Echols]

Ralph Corderoy wrote:

> >   . In non-compatible mode, the requests \f, \H, \R, \s, and \S are
> >     now grouped as `transparent escapes'; starting a line with one of
> >     them no longer preserves the beginning-of-line flag.
> 
> What perspective was used for the terminology?  It seems to me that \f,
> etc., have been made opaque, not transparent, in that they clear the
> bol flag and therefore have a side-effect.  I'm not saying it's wrong
> to call them transparent, I'd just like to know the reasoning as an
> aide memoir.
> 
> Is it really necessary to deviate groff from troff in this way?  It's
> an extra thing to document, and worse, an extra thing to be read and
> understood by everybody.  More complexity in the code, etc.  Why not
> just leave well alone and fix the troff incompatibilities.  It's not as
> if it was biting a new user every week.
> 
> It seems as if groff is a bit too keen to fix troff's perceived faults
> without weighing up the associated costs.

I agree.  There is sufficient ambiguity in AT&T troff manuals to allow
for compatibility.  Most problems can be avoided by intelligent (wise)
coding that does not exploit ambiguities and does not allow ambiguous
interpration by the *roff formatter.

I contacted one of my former collegues at HP and asked him to run the
following input text through nroff on an HP-UX system (nroff on HP-UX
is, unless I am mistaken, based on System V Release 4 AT&T Unix or newer).
Here is the input file (similar to the one used previously but with a
twist):

>  
> .de tx
> Hello world!
> ..
> abc
> \fB.tx\fP
> cde
> \fBordinary text line\fP
> more ordinary text
> and still more.
> 

Output from nroff prints the first line of regular text ("abc")
using the ordinary default font.  The remainder is in bold.

Therefore nroff is interpreting \fB.tx\fP as a request to
print the contents of macro .tx, and it is discarding \fP,
either because *roff only allows two-letter macro names with
a space following required to delimit arguments, or it is
discarding the \fP because macro .tx has no \\$1 argument in
the macro definition (which of the two is not important).

Since there is no reversion back to previous font following
execution of the macro, "cde" is printed in bold as stipulated
on the previous line.  The line following "cde" causes another
font change to font B, causing the first \fB change to become
the de facto "previous" font, and thus the \fP following the
second \fB reverts back to the first \fB font request.

To print a ".tx" in text, you have a few choices:

.B .tx   (requires macro package or a macro definition early in the file)

\fB\&.tx\fP (using none-printing space to force termination of beginning-
            of-line condition)

\&\fB.tx\fP (terminate bol before \fB)

or force \fB.tx\fP into some other sequence that keeps it away from
start of line.

Based on that, I vote for keeping compatibility with nroff/troff,
AT&T style.

Isn't Unix and its subsidiaries wonderful? :-)

Clarke "It's not nice to try to 'trick' Mother Unix" Echols 

[For you non-US participants, the preceding is a pun on a
television ad for a margarine brand that claimed, "It's not
nice to fool Mother Nature," as they promoted a product
that tastes "just like real butter".]