Re: pdfroff in groff 1.23.0.rc3 changes compared to 1.22.4

[G. Branden Robinson]

Hi John,

At 2023-04-08T23:46:52+1000, John Gardner wrote:
> > I know I will be mightily tempted to encourage others to adopt the
> > practice, in large part because "device-independent [gt]roff]
> > output" is far too long to type or speak repeatedly.
> 
> I've always just called it "ditroff" (*"device-independent troff
> [output]"*), with *.dit and *.ditroff being my typical choice of file
> extensions.

Kernighan's on the record as disfavoring the term "ditroff"[1], and I
respect the guy enough to honor his (implied) wishes here.

groff documentation has long used the term "intermediate output format",
which is a little shorter, but I'm not sure it illuminates much.

> I'm aware that it's a reappropriation of an obsolete name for all
> post-Osanna troff(1) implementations, but its meaning is clearer to
> readers familiar with the term *"device-independent [gt]roff output"*.

There is a syntactical difference between AT&T device-independent troff
output and GNU troff output.  The latter has an extension to support
multi-line device command output.  As I understand it, this is important
for PostScript and PDF.

    xX anything<line-break>
        (X-escape control command)
        Send string anything uninterpreted to the device.  If the line
        following this command starts with a + character this line is
        interpreted as a continuation line in the following sense.  The
        + is ignored, but a newline character is sent instead to the
        device, the rest of the line is sent uninterpreted.  The same
        applies to all following lines until the first character of a
        line is not a + character.  This command is generated by the
        groff escape sequence \X.  The line-continuing feature is a
        groff extension.
(groff_out(5))

groff's device-independent output has some other extensions that are
less work to support (even if just to ignore them), like the 'm', 't',
and 'u' commands, and subcommands of 'D' and 'x' ('DC', 'DE', 'DF',
'Df', Dp', 'DP', 'Dt', 'xF', and 'xU').

> The names "grout" and "trout", OTOH, are a lot less obvious.

True, but they are pleasantly whimsical, which is also a Unix tradition.
groff itself has a history of this sort of word play; see the programs
"grog" and "grotty".

I also think there is a beautifully punning name awaiting application to
Deri James's "busgrap" preprocessor.[2]

> Not to mention they'll be used interchangeably and inconsistently à la
> nroff/groff/troff).

Yes, but people will always screw up terminology; it's a lesser evil to
_have_ distinct terms for distinguishable file syntaxes.  Rather than
abandoning the discourse to the careless, I think we should have
distinct terms for those who care to communicate carefully when the
discussion calls for it.

Perhaps you can think of some alternative names for distinguishing
formatter output that we expect non-groff output drivers to be able to
cope with from those that exercise the extension.

Regards,
Branden

[1] https://manpages.bsd.lv/history/kernighan_23_10_2011.txt
[2] https://savannah.gnu.org/bugs/?55108

signature.asc
Description: PGP signature