🚀 go-pugleaf

In article <129463@sun.Eng.Sun.COM> henry%angel@Sun.COM (Henry McGilton -- Software Products) writes:
<
<Yes.  Here's the problem.  The  \fn  construct only allows a single
<digit for n (0 - 9).  If you try to be clever and type \f(nn
<where nn is a two digit number, ditroff takes this as the name of
<a font, not as a two digit font number.  For example, if you type
<\f(16, ditroff won't see this as font position 16, but as a font
<whose name is `16'.  You then get a complaint to the effect that
<there's no description file for  16.out.
<
<Now you might imagine that nobody in their right mind would
<call for fonts by number anyway, but, some of the macro packages
<save the current font number and then restore it in across sequences
<such as switching to italic, and across the bottom and top of page
<processing, and so on and so on.  The macro packages (look in -ms
<for example) tend to have sequences such as \f(\n(PQ, and these don't
<work with font positions greater than 9.
<
<I believe Elan have fixed the  \f(nn  escape sequence.  But to
<the best of my limited knowledge, DWB hasn't been fixed in this area.

I guess I won't ever attempt to go past 10 fonts, since I (not being in my
right mind :-) like to change fonts by number.  Why?  Portability.  Trying
to change fonts by name cause problems on troff cope I ship to other people
on the net.  Not all fonts have the same name on other systems.  If everyone
used Adobe Transcript, there wouldn't be a problem, but that isn't the case.

So using font numbers is a must.  I take care of the font name problem by a
file that gets loaded with the main troff file that contains the font loading
information.
-- 
                harvard\     att!nicmad\
Vidiot            ucbvax!uwvax..........!astroatc!vidiot!brown
                rutgers/  decvax!nicmad/
        ARPA/INTERNET: <@spool.cs.wisc.edu,@astroatc:brown@vidiot>