Re: Selecting Papersize

[G. Branden Robinson]

Hi Damian,

At 2023-07-09T10:56:25+1000, Damian McGuckin wrote:
> When using the -dpaper=a4 option to 'groff' (which is passed to
> 'gtroff'), the manual says to use '-P-pa4' also (which is passed to
> the backend).
> 
> Does 'gtroff' not pass enough papersize information down its pipeline
> to the backend to make that '-P-pa4' redundant?

In a word, "no".  It does not.  Kernighan's device-independent troff
design associated the paper format with the output device.

Possibly, his answer to the question of how to handle a laser printer
with multiple trays serving different paper formats would have, in 1984
or so, have been "write a device description for each tray; that way you
know what you'll be getting".

I could be wrong, because one of the things such an approach forecloses
is the possibility of printing (in one run) a document that employs
multiple paper formats.  An example that is certainly _not_ a
contrivance is the simple matter of rotating the format, so that one
could fit really wide tables onto some pages of a document using U.S.
letter or A4 paper.

Here's what we say in groff(1) about paper formats.

  Paper format
    In GNU roff, the page dimensions for the formatter troff and for
    output devices are handled separately.  In the formatter, requests
    are used to set the page length (.pl), page offset (or left margin,
    .po), and line length (.ll).  The right margin is not explicitly
    configured; the combination of page offset and line length provides
    the information necessary to derive it.  The papersize macro
    package, automatically loaded by troff, provides an interface for
    configuring page dimensions by convenient names, like "letter" or
    "A4"; see groff_tmac(5).  The formatter's default in this
    installation is "a4".

    It is up to each macro package to respect the page dimensions
    configured in this way.  Some offer alternative mechanisms.

    For each output device, the size of the output medium can be set in
    its DESC file.  Most output drivers also recognize a command-line
    option -p to override the default dimensions and an option -l to use
    landscape orientation.  See groff_font(5) for a description of the
    papersize directive, which takes an argument of the same form as -p.
    The output driver's man page, such as grops(1), may also be helpful.
    groff uses the command-line option -P to pass options to output
    devices; for example, use the following for PostScript output on A4
    paper in landscape orientation.

        groff -Tps -dpaper=a4l -P-pa4 -P-l -ms foo.ms > foo.ps

It is conceivable that we could add formatter and output driver features
to permit alteration of the paper format mid-document, which would also
permit a non-default to be specified only once at the outset, which is
your use case.  We seem to already support this in a couple of drivers.

gropdf(1):

    One \X device control command used by the DVI driver is also
    recognised.

    \X'papersize=paper-format'
        where the paper-format parameter is the same as that to the
        papersize directive.  See groff_font(5).  This means that you
        can alter the page size at will within the PDF file being
        created by gropdf.  If you do want to change the paper format,
        it must be done before you start creating the page.

So we might want to think about porting this feature to our other
troff-mode (i.e., typesetting) output drivers.  Since grodvi is in C++,
this shouldn't even be hard (famous last words).  But I've never looked
into it.

There is also the matter of wiring things up on the input end.  We might
want to have papersize.tmac define a macro that recomputes the
appropriate registers and invokes `ll` and `pl` requests anew.

Another factor to account for is that our macro packages (possibly
excepting mom(7)) are not written in the expectation that the line and
page lengths can change across a page break.  As they stand, I am
confident that the outcome of implementing the above and exercising this
feature while using these packages would be bad.  They would need to be
modified appropriately.

The coordination of these multiple moving parts is, I would guess, the
main reason this work has not already been done.

Regards,
Branden

signature.asc
Description: PGP signature