Re: [Groff] inconsistency between .R and \*R in man.tmac

[Clarke Echols]

Tadziu Hoffmann wrote:

> My guess is that the author of the manpage simply assumed ".R"
> was missing from the description and added it to the manpage
> without checking whether it was really implemented.
> 
> > It seems that scraping .R and keeping \*R is what would be compatible
> > with the man pages out there.

Quite frankly, I cannot conceive of a reasonable situation where
".R" for Roman would be needed.  If your base font is R (font position 1),
all macros should process their text in their own font, then restore font
1 upon completion.  Therefore there should be no need to "force" an R font.
I'm thinking in terms of ".B", ".BR", ".IB", etc.

In the literally thousands of manpage files I processed over a period of
years, I NEVER encountered a need for ".R" or anything like it.  On occasion,
I might want to produce a block of text in a single font, but I used direct
troff coding as when displaying example blocks of software code:

  .P
  .nf       \" start no-fill mode
  .ft 4     \" C font
  .ps -1    \" drop point size one point for artistic reasons
  text here
  more text
  still more text
  .ps +1    \" restore point size
  .ft 1     \" restore Roman (base) font
  .fi       \" restore fill mode
  .P

All of my "C" font macros also dropped the Courier point size by one point
to make it look nicer when keywords and literals were sprinkled in ordinary
text (I was using New Century Schoolbook fonts).

It is important in such instances to specify font in terms of font position
rather than using "R".  That way you can change the fonts in an entire
production by changing a few lines in the macro file instead of searching
an entire book.  Using "\fR" instead of "\f1" would give Times Roman
instead of returning to New Century Schoolbook Roman.  That'll really
screw up a production manual.

Clarke