Hi Karl, Another lengthy response. I fear TeX advocates will care little or nothing for the material herein. Sorry. I beg the indulgence of the victors in the typesetting system war.
At 2026-04-20T15:18:40-0600, Karl Berry wrote:
> Hi Branden - thanks much for all the info.
My pleasure!
> My remaining question is: does "\f(CW" cause a warning with current
> groff? (Sorry, it's not something I can easily test.)
Yes. The warnings differ depending on whether you're formatting for a
terminal ("nroff mode") or a typesetter ("troff mode").
$ printf '\\f(CWHello, world!\n' | nroff -a
troff:<standard input>:1: warning: cannot select font 'CW'
<beginning of page>
Hello, world!
$ printf '\\f(CWHello, world!\n' | groff -a
troff:<standard input>:1: warning: font name 'CW' is deprecated [-w font]
<beginning of page>
Hello, world!
> And if it does, what should I use?
If typesetting, `CR` ("Courier roman") has been the way to get it on all
of groff's typesetting output drivers going back to about 1990. Since
groff 1.22.4 in 2018, I've enhanced the man pages of groff's output
drivers (grops(1), grodvi(1), grotty(1), and so on) to enumerate the
typefaces they support.
If not typesetting, use nothing. Terminal fonts are already
"typewritten" a.k.a. monospaced.
If that's not the answer you wanted to hear, keep reading. I have
alternatives.
> Or is there in fact no way whatsoever to get inline typewriter in man
> pages without (now) a warning? That would be a bad outcome.
People who never typeset man pages would likely tell you not to ever
bother--a terminal emulator window is the only interface that matters.
Fortunately for our discussion, I am not among those people.
If you are bent on inline Courier, then at the risk of rousing the ire
of mandoc(1) maintainer Ingo Schwarze, I suggest a possibility: write
page-local macros to meet the scenario you have in mind.
Here's an example:
.de CS \" Courier start
. if \n(C_ .ab don't nest me, bro
. if n .ft B
. if t .ft CR
. nr C_ 1
..
.
.de CE \" Courier end
. ft
. nr C_ 0
..
The foregoing is as portable as I can make it. It uses no groff syntax
extensions. The font name `CR` is imperfectly portable because AT&T
troff offered no infrastructure or registry for standardized font
identifiers. Implementations therefore diverged.
Below, I present another possibility that doesn't involve defining
macros, and doesn't require you to abandon the `\f(CW` input pattern.
I advise careful review of documents that pivot readily between
proportional and monospaced typefaces inline. I weaned groff mdoc(7)
off of this habit in our 1.24.0 release, another move I fear may earn
me remonstration from Ingo Schwarze.
NEWS:
* The doc (mdoc) macro package now performs font family switches
inline (that is, on the same output line) to Courier much less
frequently when formatting for typesetters, affecting the `Ar`, `Cm`,
`Er`, `Fa`, `Fd`, `Fl`, `Fn`, `Ft`, `Ic`, `Li`, and `Nm` macros.
This change was made to reduce the ambiguity of space widths when
typesetting the monospaced Courier and proportional Times fonts
adjacently. Bear in mind that you can use the "mdoc.local" file to
customize the font used to render nearly any mdoc(7) macro's
arguments; this mechanism has been in place since 1992.
Background:
https://lists.gnu.org/archive/html/groff/2024-03/msg00152.html
https://lists.gnu.org/archive/html/groff/2024-03/msg00199.html
> I don't need perfect portability.
I'm glad you said that, because I don't know good a way to achieve it.
AT&T troff offered no way to query the system for font availability.
Loading up every man(7) document with a set of Autoconf-like tests to
infer the formatter's vendor and version, and presuming that one could
deduce font availability thence (when you _actually could_ extend AT&T
troff's font repertoire[9]), seemed like a terrible alternative to me.
> I just need something that works with GNU groff without complaint.
The foregoing should do it. As an alternative, I submitted a quotation
macro to GNU Bash for use in its man page a while back, and Chet Ramey
graciously accepted it.
.\" Quotation macro: generate consistent quoted strings that don't rely
.\" on the presence of the `CW' constant-width font.
.\"
.de Q
.ie \n(.g \(lq\\$1\(rq\\$2
.el \{\
. if t ``\\$1''\\$2
. if n "\\$1"\\$2
.\}
...though he also wanted a version that suppressed hyphenation, so he
added a second macro.
.\" Q but disallowing hyphenation of the string
.de QN
.ie \n(.g \%\(lq\\$1\(rq\\$2
.el \{\
. if t \%``\\$1''\\$2
. if n \%"\\$1"\\$2
.\}
..
> .EX/.EE are good, but not all typewriter is displayed.
Perfectly true.
> I have a few more general comments. Sorry for my persistence. Feel
> free to ignore all this.
No, I appreciate the feedback.
> versions of groff weren't able to "select font 'C'" either,
>
> The output from \fC was/is typewriter. So the right thing happened.
But, on terminals, the same "right thing" would happen with \fQ, \fJ, or
\f(ZZ, so that observation doesn't feel weighty to me. There are lots
of ways to do nothing in the *roff language.
Though as I'll show in a moment, the exact meaning of "doing nothing",
when it comes to font selection specifically, differs among troffs.
> is that the formatter cannot honor the request that is being made
> of it. No font "C" exists to select.
>
> I understand. But maybe you could define it, instead of trying to
> stamp it out. It has a clear meaning and has worked for decades for
> many people.
I'm not eager to establish semantics for a dummy font and how it
interacts with the formatter's internal datum of the previous font
selection.
> (1) it never accomplishes anything on any terminal device anywhere
> and
>
> Sure. But it also doesn't hurt anything. Selecting a monospace font is
> a harmless no-op for terminals.
I'm afraid I have to unveil something horrible to you.
First, some necessary background.
groff(7):
.ft
.ft P Select previous font mounting position (abstract style or
font); same as \f[] or \fP.
.ft font Select typeface font, which can be a mounting position,
abstract style, or font name; same as \f[font] escape
sequence. font cannot be P.
...
.tm message
Write message, followed by a newline, to the standard
error stream.
...
\n[.f] Mounting position of selected font; see .ft and \f.
Note also that `\n(.f` is AT&T troff syntax for the last item above.
Now consider the following input.
.de TM
.tm .f=\n(.f
..
.ft B
.TM
.ft ZZ
.TM
.ft P
.TM
Predict the output of the foregoing document.
*
*
*
*
SPOILER SPACE
*
*
*
*
[Solaris 10]$ printf '.de TM\n.tm .f=\\\\n(.f\n..\n.ft B\n.TM\n.ft ZZ\n.TM\n.ft
P\n.TM\n' | nroff
.f=3
.f=3
.f=1
$ printf '.de TM\n.tm .f=\\\\n(.f\n..\n.ft B\n.TM\n.ft ZZ\n.TM\n.ft P\n.TM\n' |
groff -E
.f=3
.f=3
.f=3
$ printf '.de TM\n.tm .f=\\\\n(.f\n..\n.ft B\n.TM\n.ft ZZ\n.TM\n.ft P\n.TM\n' |
groff -E
.f=3
.f=3
.f=3
$ printf '.de TM\n.tm .f=\\\\n(.f\n..\n.ft B\n.TM\n.ft ZZ\n.TM\n.ft P\n.TM\n' |
9 nroff
.f=3
.f=3
.f=1
$ printf '.de TM\n.tm .f=\\\\n(.f\n..\n.ft B\n.TM\n.ft ZZ\n.TM\n.ft P\n.TM\n' |
dwb nroff
.f=3
.f=3
.f=1
$ printf '.de TM\n.tm .f=\\\\n(.f\n..\n.ft B\n.TM\n.ft ZZ\n.TM\n.ft P\n.TM\n' |
heirloom nroff
.f=3
.f=3
.f=3
And here's Ali Gholami Rudi's neatroff, which lacks an nroff command.
$ printf '.de TM\n.tm .f=\\\\n(.f\n..\n.ft B\n.TM\n.ft ZZ\n.TM\n.ft P\n.TM\n' |
neatroff >/dev/null
.f=3
neatroff: failed to mount <ZZ>
.f=3
.f=1
Perhaps you see the problem.
Switching to a different typeface, and then switching "back", is an
idiom employed with overwhelming frequency in man pages. Worse,
document authors commonly do so directly with formatter features,
instead of employing the font alternation macros that the man(7) package
has offered for font selection since 1979. People go straight to the
formatter with `ft` and `\f`--I suppose because there's nothing better
than being "close to the metal". Or maybe it is thought "cooler" to
defeat spell checkers...
eschewing
.I this
kind of emphasis in favor of \fIthis\fP.
:-|
Too many man page authors cling to font selection escape sequence syntax
like Bourbons to the throne. They learn nothing, and forget nothing.
Anyway, you can see the practical problem. You can't predict what font
your text will set in--even on terminals--if the selection failed and
you dutifully reverted to the "previous" face.
I have to thank perlpod(1) maintainer Russ Allbery for bringing this
misfortune to my attention some years ago.
I think the problem comes down to inadequately specified language
semantics. When you select a font that doesn't exist, have you done
"something" or have you done "nothing"? (I challenge troff mavens to
find a clear answer in CSTR #54--any revision thereof.) Implementations
differ, I guess depending on whether they give greater weight to the
perspective "user attempted an operation" or "the formatter performed an
operation". I figure either choice is defensible. Ambiguity is a
hazard we face when we design a language without a complete, formal,
machine-verifiable specification.
> because there is no such thing as a portable font name in *roff,
>
> If it works in groff, that's good enough for a huge proportion of roff
> users nowadays (including me).
I think so too. But I feel that part of my responsibility as groff
maintainer is to be mindful of other implementations, especially ones
that are Free Software (though some lack GPL-compatible licenses), so
that, when innovating, groff does so either non-disruptively to those
other implementations or can justify its decision to pursue an
incompatible course strongly enough that a neutral observer would be
persuaded that our decision was reasonable. (Partisans, you'll never
convince.)
Further, studying AT&T troff, its historical implementations,
manuals, and documentation produced using it, has taught me more than I
can measure about why GNU troff works the way it does, and I'm sure has
prevented me from wasting time on various boneheaded reforms.
I pursue plenty of other boneheaded reforms even lacking the advantage
of total ignorance. ;-)
> Many people in many situations do not need perfect portability. E.g.,
> I have no problem telling people that man pages in TeX Live should be
> processed with groff.
Thank you! I hope never to give you reason to waver from that stance.
> There is no completely portable way to select a monospaced
> typeface when using the man(7) macros. The package was not
> designed to do so,
>
> I understand, but it would nevertheless be useful if it was
> ameliorated. Typewriter is one of the things most needed in man
> pages.
...but it doesn't show up distinctly on a terminal! I feel that by not
taking that into account you risk failing to reach a big chunk of your
audience.
While this principle is a guide star for me:
"The manual was intended to be typeset; some detail is
sacrificed on terminals." (man(1), _Unix Time-Sharing System
Programmer's Manual_, Eighth Edition, Volume 1, February 1985)
...I can't escape the fact that lots of people reading man pages simply
will never do so on anything but an xterm or similar.
> And I believe man pages are a significant proportion of all roff use,
> nowadays.
Yes. A while back I inspected the Debian Project's "popcon"
installation figures for its packages "groff-base" (all you need for man
pages) and "groff" (the full system). Man page users seemed to
outnumber the rest by a factor of 8 to 10.
> original troff (Ossanna troff)
>
> Yes, I'm aware of (t)roff history and why it was defined as it was in
> the 1970s, for the C/A/T typesetter at Bell Labs, which didn't have a
> place to "mount" Courier.
They had a place--a "mounting position". If you ponied up and purchased
a typewriter font (on photographic film), you could "mount" that
physical object in the carousel, which, as I understand it, had four
mounting positions on the CAT-4 and eight on the CAT-8. If you were
penurious enough to have only the less capable model, you had to
sacrifice a font to put Courier in its place. I believe this is how
K&R's original _The C Programming Language_ (1978) was typeset.[9] And
possibly, this is why Joe Ossanna devised the `bd` request.
> But it seems like GNU groff doesn't need to be limited by that, some
> 50 years later.
Certainly not. The problem here is more that terminal emulators can't
change the font family dynamically, and even if they could there's no
standardized interface grotty(1) can use to drive it in this respect. I
implemented OSC 8 support--uptake seems slow, and users indifferent.
https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=1.23.0#n223
https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=1.23.0#n548
> Do you think it would help if I added the foregoing paragraph to
> to the "Notes" section of groff_man_style(7), given that is serves
> as a kind of "man FAQ"?
>
> Yes. Any specific information about this question would be helpful,
> IMHO. Also in groff_man_style and/or man(7), especially in that
> section describing .EX/.EE. Anyone reading that will, more than
> likely, want to know about non-displayed typewriter too.
Okay. Maybe I can add an admonition about the hazards of attempting
inline changes of typeface--beyond what's already documented--with
hopeful leaps into the dark.
> My goal in improving groff's diagnostic messages (and increasing
> the variety of them) is not to make people jump through hoops but
> to enable
>
> I understand, and agree that it's a laudable goal in general. However,
> the end result in this case does turn out to be making me "jump
> through hoops" because, as you've seen, as soon as there is a warning,
> it gets reported, and since I don't want to receive a stream of
> warnings from multiple people over multiple years, I have to fix it.
> Even though this man page has rendered perfectly well for decades. If
> the man page had rendered incorrectly, I wouldn't be complaining ...
I think the problem can be attacked from three angles: user self-help,
man(1) command support, and improvement of man page content.
User self-help
--------------
> Changing options or envvars or processing doesn't really help, because
> the reports always come from people who use their own build
> environments.
Ah, I see you anticipated this angle already. I might have said some of
the following earlier in the thread; if so, I apologize for the
duplication.
For the record, man-db man(1) supports the environment variable
`MANROFFOPT`, so people can do the following depending on their level of
tolerance for diagnostics:
export MANROFFOPT=-Wfont
export MANROFFOPT=-Wall
export MANROFFOPT=-E
Another approach is to modify the man.local file:
groff_man(7):
/usr/local/share/groff/site-tmac/man.local
Put site‐local changes and customizations into this file.
groff_man_style(7) adds concrete examples addressing issues about which
users have complained:
.\" Put only one space after the end of a sentence.
.ss 12 0 \" See groff(7).
.\" Keep pages narrow even on wide terminals.
.if n .if \n[LL]>80n .nr LL 80n
Maybe I should add:
.\" Silence font selection warnings.
.warn \n[.warn]-131072
(Yes, that syntax is incomprehensible and horrendous. I aim to fix
it.[1])
man(1) command support
----------------------
The man-db man(1) command could specify some default `-w` and/or `-W`
arguments to groff if the `MANROFFOPT` environment variable is not
defined. This is a judgment call for Colin Watson, its maintainer. I
tune groff's defaults for what seems like idiomatic usage of the
commands groff(1), nroff(1), and troff(1), because that's what groff
_supplies_. Users commonly fail to perceive the distinct
responsibilities of man(1) as a librarian--a program that locates
documents to help you--and *roff, a typesetting formatter or renderer.
(mandoc(1) mashes both functions back together again into a single
process and address space; its partisans consequently boast of its
faster performance relative to man(1) and groff(1), attributing that to
superior programming prowess on the part of OpenBSD developers--and its
choice of a superior implementation language.) This point seems
frequently overlooked even by people who readily parrot the common
refrain that Unix is a brilliantly designed system because it affords
program composition through pipelining. They'll tout this fact in one
breath and forget it the next, as soon as they want to read a man page.
All of a sudden these close-to-the-metal sophisticates conform to
limitations Steve Jobs imagined of the original Macintosh users of the
1980s, unable to handle a mouse with more than one button.
I can't account for this.
Improvement of man page content
-------------------------------
This is the most worthwhile, most important, but ultimately most
difficult avenue of improvement because it makes demands of the man page
author, not the user, not the man(1) maintainer, and not me as groff
maintainer. (It _does_ apply to me when I undertake to write man pages,
which I do a fair amount of.)
Recall this bit from above:
"I advise careful review of documents that pivot readily between
proportional and monospaced typefaces inline."
If you ever mean to set more than one word at a time inline with a
typewriter face, then this is for you. I faced a similar challenge in
groff's "ms.ms" document. Larry Kollar originally wrote the manual, but
didn't design it for terminal rendering. In Research Tenth Edition Unix
(1989), the ms(7) package grew a macro that groff cloned.
groff_ms(7):
.CW [text [post [pre]]]
As B, but use a constant‐width (monospaced) roman typeface
instead of bold. This is a Research Tenth Edition Unix
extension.
So, what happens to text marked up this way when it's rendered in nroff
mode?
Nothing.
What's the _right_ thing to do? Depends on the document. This is
ms(7), not man(7), so we know a real *roff formatter, not some man2html
scraper or mandoc(1) program is formatting it, and moreover a principle
of _ms_ document composition is that the author is au fait with *roff.
Maybe not enough to write a full-service macro package on their own, but
pretty capable.
Having thrashed on "ms.ms" to get it nroff-ready, I found myself facing
the exact problem you are. Here's my solution.
.if n \{\
. ftr CR B \" for a visible distinction from roman
.\" ...
.\}
Pretty simple, eh? I didn't need an `.if \n(.g` test to check for a
groff-compatible formatter because groff ms's macros work only with a
groff-compatible formatter anyway.
This isn't a magic bullet. What happens if you set bold and Courier
roman adjacently? No distinction. The reader will get confused. So
attention to the document's content is a must.
You could adapt this solution to your man page(s) as follows.
.if n .do ftr CW B \" for a visible distinction from roman
(Why "do"?
groff(7):
.do name argument ...
Interpret the string, request, diversion, or macro name
(along with any further arguments) with compatibility
mode disabled. Compatibility mode is restored (only if
it was active) when the interpolation of name is
interpreted.
Because AT&T troff doesn't define a `do` request, it interprets ".do ftr
CW B" as a macro call...of an undefined macro, which is created, made
empty, interpolated, and does nothing.)
> groff's Texinfo manual does not cover macro packages,
> preprocessors, or output drivers in detail, except for the "ms"
> package [0]
>
> I see. It feels unfortunate, since, as I mention above, I believe man
> pages are a primary use of roff. Indeed, it never occurred to me that
> man pages would *not* be covered in the groff manual.
groff faces competing pressures in this area.
* It's an official GNU mandate(?) that all GNU packages shall have a
manual in Texinfo format.[2]
* Perhaps an exception was made for groff in early days (~1989) because
for many years, it lacked one, yet retained official GNU status.
* In 1999, Trent Fisher contributed a Texinfo manual for groff, adapting
James Clark's man pages for groff but adding considerable material of
his own. First Werner Lemberg and then I (have) continued to update
it over the years. I think Dave Kemper observed that (what is today)
"doc/groff.texi.in" is the single most revised file in groff's Git
repository. I know for sure that running a "git blame" on it takes
perceptible time.
* As I understand it, the reason for GNU's selection of Texinfo as its
official documentation format was because it was capable of targeting
multiple output formats using a single master document, so the GNU
project developers didn't have to maintain documentation in multiple
formats. I've gotten the impression that a contributing factor was
that the syntax of Brian Reid's Scribe was thought important to clone.
* That's exactly how groff works, too. But I guess not syntactically
resembling Scribe led to its neglect or derogation.
* People occasionally wonder why groff "doesn't have a manual in its own
format".[3] They ask this partly out of awareness of groff's Texinfo
manual, partly out of ignorance of the rest of groff documentation,
which is extensive,[4] and partly to suggest some kind of hypocrisy
and/or technical inadequacy of either or both projects as a means of
amusing themselves around the metaphorical water cooler.
* Not long after joining groff development in 2017, I decided that
tackling its documentary challenges was my first priority, largely
because I've found that the best (only?) way I can evaluate and
_eventually_ master a software system is to subject what documentation
it has to intense scrutiny. I swiftly reached the conclusion that
groff's Texinfo manual did a good job of documenting the formatter,
the groff(1) command-line interface, and the ms(7) macro package, and
made almost no effort to document any other part of the system.
Further, a previous maintainer, Werner Lemberg, pointed out the work
he had done on that manual and observed correctly that GNU troff was a
sufficiently complex system that something more than a reference page
was warranted. Quite right: that's why multiple releases of the AT&T
Unix Programmer's Manual shipped a "Volume 2"; whereas Volume 1 was a
dump of the collected man pages in typeset form, Volume 2 housed
whitepapers containing much valuable material, some tutorial, some
research-oriented, but all essential supplements to the man pages
where the topic was relevant. (That observation supported one I had
made in the 1990s that a lot of Unix nerds pretended to each other
that they learned the whole system from just the man pages and sheer
personal aptitude, when in truth, a lot of them got a hold of the
chained-up, off-line, "forbidden" literature and consumed that while
also creating a mystique around themselves that they actually learned
that material exclusively through absorption of Ken Thompson's
impenetrable source. Possibly the samizdat practices that grew up
around the Lions book, themselves a product of AT&T's insatiable
avarice for revenue from computing systems, encouraged this loathsome
culture of elitist gatekeeping--still going strong among tech bros.)
Thus an opportunity presented itself.
I could whittle down groff's Texinfo manual to cover only the
formatter itself (or "Core" as we term it in Savannah's bug tracker),
the eponymous orchestrator program's command line (because such Info
users as _do_ exist expect an 'Invocation' node), and some
introductory and tutorial material. Other subjects, like
preprocessors, macro packages, and auxiliary utilities are covered in
man pages, and, if sufficiently complex to warrant them, supplementary
manuals composed using groff itself. We have "ms.ms", "pic.ms",
"meintro.me", and "meref.me", for example.
The material on the ms(7) package in our Texinfo manual remains until
I can replace it with something "better".[6]
Anyway, if you feel groff is lacking other documentation, I direct your
attention to our collected man pages[7] for a start.
> (I guess it should have been obvious to me, but, as usual, I was just
> looking for an answer to my particular question, not reading the
> background or looking at the overall document.)
That's fine. Not everybody can have great depth in every subject.
> Anyway, since I gather you have no desire to expand the manual to
> cover the man macros (and I can understand why), maybe a brief list of
> common macro packages and where to find their documentation somewhere
> near the beginning of groff.texi?
On page 10 of groff's Texinfo manual,[8] we document the groff command's
`-m` option, which loads macro packages. I see that we could add a list
of "full-service" macro packages, with citations of man pages thereto--
employing a syntax I had to invent for this Texinfo manual, the idea
having evidently been unthinkable heretofore: just as an Emacs user
never leaves Emacs, an info(1) user never leaves info(1). We already do
a similar thing in the synopsis of the `-T` option for selecting an
output device, so I perceive no incongruity here.
And besides, the list of full-service macro packages is much shorter
than the list of output devices.
> I had never heard of groff_man_style(7) before you mentioned it. In
> fact, it does not exist on my computer. I guess it was created in a
> newer release than what I currently have.
It showed up in groff 1.23.0, released July 2023. I wear the credit or
blame for its existence: I noticed that a lot of material on the Web
about writing man pages was some combination of incorrect, incomplete in
the sense that it didn't point out common idioms or style practices, or
20 years out of date. For example, groff 1.20 (2009) added several
highly worthwhile new macros for support of a shiny new concept called
"hyperlinks" ;-) and a few more to ease formatting operations that many
many page authors performed clumsily, like stacking paragraph tags or
writing command synopses. That release also resurrected an old idea
from Ninth Edition Unix (1986): monospaced displays, which had gotten
forgotten about because SunOS and Solaris never bothered to incorporate
the feature, and so groff never had, either.
> Thanks again for the exhaustive reply and all your work on groff.
Thanks for your patience with my responses.
Regards,
Branden
[1] https://savannah.gnu.org/bugs/?68242
[2] Maybe "presumption" would be a better term than "mandate".
"The web pages for the package should include its manuals, in HTML,
Info, PDF, plain ASCII, and the source Texinfo."
https://www.gnu.org/prep/maintain/maintain.html#Manuals-on-Web-Pages-1
[3] https://lists.gnu.org/archive/html/groff/1999-05/msg00004.html
https://www.reddit.com/r/groff/comments/18bjbv6/did_they_author_groff_manual_through_groff_macros/
https://lists.gnu.org/archive/html/groff/2022-07/msg00182.html
[4] ...both the ignorance and the documentation.
https://www.gnu.org/software/groff/manual/
In the future, as we get PDF bookmarking features added to more of
our full-service macro packages (starting with ms[5]), I'll be
thrilled to add our ms, me, and pic manuals to that page.
[5] https://savannah.gnu.org/bugs/?67665
[6] https://savannah.gnu.org/bugs/?60061
[7] https://www.gnu.org/software/groff/manual/groff-man-pages.pdf
[8] https://www.gnu.org/software/groff/manual/groff.pdf
[9] ...in Kernighan's device-independent troff, that is. If Ossanna
troff has a means of achieving this, I don't know what it was. If
one exists, I'll bet System III's cw(1) exercised it.
signature.asc
Description: PGP signature
