The problem is that at no point you can have the .roff source, after
the man(7) macros have been expanded. Would it be possible to split
the groff(1) pipeline to have one more preprocessor, let's call it
woman(1) (because man(1) is already taken), so that it translates
man(7) to roff(7)? I'd like to be able to do this:
$ preconv foo.1p >foo.1p.tbl
$ tbl <foo.1p.tbl >foo.1p.eqn
$ eqn -Tutf8 <foo.1p.eqn >foo.1p.man
$ woman -Tutf8 <foo.1p.man >foo.1p.roff
$ troff -Tutf8 <foo.1p.roff >foo.1p.set
$ grotty -c <foo.1p.set >foo.1p.cat
It couldn’t work with a preprocessor with any degree of
generality.¹ The macro definitions themselves are entirely
context-dependent; the easiest thing to point to for that is
changing the control characters.
.cc c
cde m
.\" ...
..
There are countless examples requiring such a preprocessor to
interpret the troff language.
What might be possible is a mode for troff that emits text and
control lines every time nodes would be added to the internal
buffer. (Or something; I don’t know the internals.) Though
that would absorb the environment’s effects, like the nroff/troff
distinction, that should be applied when the document is rendered.
What might be fun is writing a postprocessor that emits troff,
though the resulting troff would look even uglier than that of
a mode of troff the program.
Oh, and do note that mandoc likely wouldn’t be able to render such
documents nicely.
Easier options are:
a) letting man-db accept trout man pages, with the same issue
with mandoc
b) bundling the macros with the man pages with a little .so at
the start, with the same issue with mandoc
c) shipping pre-rendered cat pages, with little annoyances such
as the inability to render the man page at different sizes or
disabling SGR mode or using a different encoding
With man(7) alone, it's already interesting to have this for
debugging purposes. But I envision a more useful thing: POSIX uses
mm(7) for their manual pages. Ideally, I'd like to keep their
sources with minimal modification in man-pages-posix. But of course,
man(1) only understands man(7) and mdoc(7). If we add a mm(1)
program that is the mm(7) equivalent of woman(1), then I'd be able
to install a preprocessed page, with the following pipeline, and
man(1) should be able to render it, I guess:
$ preconv foo.1p >foo.1p.tbl
$ tbl <foo.1p.tbl >foo.1p.eqn
$ eqn -Tutf8 <foo.1p.eqn >foo.1p.man
$ mm -Tutf8 <foo.1p.man >foo.1p.roff
$ install foo.1p.roff /usr/man/man1p/foo.1p
Btw, mm(1) is already taken for a System V script roughly similar
to troff -mm "$@" with a few extra options for specifying the use
of preprocessors or nroff. I don’t see value in having
specialized programs for different macro packages in this way, for
that purpose or for this.
¹ The use of preprocessors that don’t parse troff is a hack
anyway. If usually not much of a concern, it is annoying if you
need to replace
.cc @
@ EQ
by
.cc @
.EQ
(Not that I often use .cc.)
