groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: process man(7) (or any other package of macros) without typesetting


From: Lennart Jablonka
Subject: Re: process man(7) (or any other package of macros) without typesetting
Date: Thu, 17 Aug 2023 23:11:09 +0000

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.)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]