🚀 go-pugleaf

In article <22078@sgi.SGI.COM> andru@rhialto.SGI.COM (Andrew Myers) writes:
>For some reason, the following piece of input to nroff fails to work
>properly on my system. However, as an input to our variant of
>troff it functions quite nicely. The symptoms of the problem are a
>return to the italic font following the word "system". On my system,
>nroff simulates this effect by underlining the remainder of the
>sentence. I would expect (and troff bears me out) that it would return
>to the Times-Roman, ordinary font. Any thoughts? Do other people have
>this problem? -Andrew
>
>---------------- cut here ---------------
>.fp 1 R
>.fp 3 H
>.ft 1
>.ps 12
>
>This is a test \fIof\fP the \fBsystem\fP. Undoubtedly, it will fail.

I beleive what is happening is that by specifying font 3 to be 'H'
(Helvetica?), you are overwriting the 'B' that is by default in
position 3. When you then select font 'B' with "\fB", it can't find
a font called 'B' (since it has been overwritten with 'H') and remains
in the current font. The following switch to the previous font ("\fP")
goes back to italic. Since there never really was a font change when
nroff couldn't find font 'B', the previous font remained italic, not
roman.  If you instead use "\f3" instead of "\fB", you will get the
expected result with nroff.

The reason that it works with troff is that even though you mounted
font 'H' in the default position for font 'B', font 'B' will get
temporarily mounted (by loading the "B.out" file) in position 0 when
you request it. Since nroff doesn't use the *.out font tables that
troff uses (it has a much more simplistic system), it doesn't temporarily
mount fonts, and won't know about font 'B' after mounting another font
on top of it.

I hope this helps.
-- 
Jeff Lo
..!{ames,hplabs,uunet}!elan!jlo
Elan Computer Group, Inc.
(415) 322-2450

In article <22078@sgi.SGI.COM> andru@rhialto.SGI.COM (Andrew Myers) writes:
>For some reason, the following piece of input to nroff fails to work
>properly on my system.
>....					Do other people have
>this problem? -Andrew

This also fails on Apple's A/UX.  I noticed exactly the same problem
some months ago while writing some documentation, but wrote it off as
just an A/UX glitch.  Looks like I was wrong.  The only cure I could
find was to use \fR in place of \fP, wherever it broke.

-Fred
-- 
# Fred Fish, 1346 West 10th Place, Tempe, AZ 85281,  USA
# noao!nud!fishpond!fnf                   (602) 921-1113