gropdf landscape orientation support (was: [groff] 04/40: [gropdf]: Provide more info in diagnostic message.)

[G. Branden Robinson]

[dropping groff-commit since this part of the conversation is no longer
about a past commit]

At 2022-11-17T01:22:48+0000, Deri wrote:
> > > I thought it best not to push my latest fixes for the landscape
> > > hotspot issue notified by Blake until you have done your reverts.
> > 
> > I don't think that is necessary; the hunks of your diff affect lines
> > ca.  319 and 1490 of "gropdf.pl".  The commit to which you're
> > objecting (4753f2b17b8d836cf66fcb17f5412239e8b45743) altered lines
> > around 676 and 2555.  In my experience that is easily generous
> > enough spacing; git reverts are not limited to the immediately
> > previous change to a file.
> > 
> > So I think it unlikely that any changes to relocate the hotspot will
> > interfere with font embedding-related work.
> > 
> > > But I have attached them as a diff to gropdf before your changes,
> > > so can be applied after.
> > 
> > It need not wait; feel free to go ahead and commit now.  If you'd
> > prefer I did it for whatever reason, let me know--I'll take care of
> > it, with you as --author of course.
> 
> That would be very kind, thank you. Please note as well as the rotated
> landscape hotspot fix, it includes appending L or l to papersizes,
> i.e. -p LetterL would specify a landscape letter paper size.

Just to make sure I understand: you are saying that the "-P-l" option to
groff is unnecessary if "pdf" is the output device and the paper format
is suffixed with "l" (case-insensitively)?

I confess to some uncertainty about the wisdom of this, since there is
already a "-l" option recognized across most typesetting output drivers
for using landscape orientation.  It thus seems that the possibility
arises for a conflict between DWIM and taking the user literally.  E.g.,
should "-P -p -P legall -P -l" result in a portrait orientation of U.S.
legal paper?

In trying various combinations, here are my findings.

groff 1.22.4:
groff -ms -Tpdf EXPERIMENTS/lorem.ms
        expectedly OK
groff -ms -Tpdf -P -l EXPERIMENTS/lorem.ms
        expectedly BAD (right margin huge, text overruns page bottom)
groff -ms -Tpdf -P -p -P letterl EXPERIMENTS/lorem.ms
        unexpectedly OK (ordinary portrait output)[2]
groff -ms -Tpdf -P -p -P letterl -P -l EXPERIMENTS/lorem.ms
        expectedly BAD (we never told the formatter we wanted landscape)
groff -d paper=letterl -ms -Tpdf EXPERIMENTS/lorem.ms
        expectedly BAD (bottom margin huge, lines overset on right)
groff -d paper=letterl -ms -Tpdf -P -l EXPERIMENTS/lorem.ms
        OK (though the page margins are asymmetric; maybe ms's fault)
groff -d paper=letterl -ms -Tpdf -P -p -P letterl EXPERIMENTS/lorem.ms
        BAD (not sure if I should have expected this or not)
groff -d paper=letterl -ms -Tpdf -P -p -P letterl -P -l EXPERIMENTS/lorem.ms
        OK (though the page margins are asymmetric; maybe ms's fault)

Now here's my working copy with your Landscape.diff applied.

groff Git WC ('*' at line end indicates change from groff 1.22.4):
test-groff -ms -Tpdf EXPERIMENTS/lorem.ms
        expectedly OK
test-groff -ms -Tpdf -P -l EXPERIMENTS/lorem.ms
        expectedly BAD (right margin huge, text overruns page bottom)
test-groff -ms -Tpdf -P -p -P letterl EXPERIMENTS/lorem.ms
        expectedly BAD (right margin huge, text overruns page bottom)*
test-groff -ms -Tpdf -P -p -P letterl -P -l EXPERIMENTS/lorem.ms
        unexpectedly OK (back to portrait!)*
test-groff -d paper=letterl -ms -Tpdf EXPERIMENTS/lorem.ms
        expectedly BAD (bottom margin huge, lines overset on right)
test-groff -d paper=letterl -ms -Tpdf -P -l EXPERIMENTS/lorem.ms
        OK (page margins look nice now)
test-groff -d paper=letterl -ms -Tpdf -P -p -P letterl EXPERIMENTS/lorem.ms
        OK (but I wasn't honestly sure what to expect)*
test-groff -d paper=letterl -ms -Tpdf -P -p -P letterl -P -l 
EXPERIMENTS/lorem.ms
        BAD (bottom margin huge, lines overset on right; not sure if I
        should have expected this or not)*

I think my brain would relax somewhat from the pretzel shape it adopts
when contemplating the above results if either:

1.  gropdf stopped attempting magical parsing of a trailing 'l' in the
    paper format.  I don't think any other groff output driver does so.
    This novelty saves a few keystrokes of typing (which for most groff
    _users_ producing practical documents--as opposed to developers
    poking things with sticks--are best kept in a shell function, shell
    script, or Makefile), at the expense of frustrating knowledge
    transfer to and from other groff output devices.

or

2.  gropdf deprecated the '-l' option, warning upon its use, and
    documenting alternatives in the man page.  (These would be: if you
    want a predefined format in landscape, just use "-P -p" and tack an
    "l" on as a suffix, and if you're using a custom paper format with
    explicit dimensions, just swap their order.)

I will go ahead and commit your change, and it will be in my push unless
you get back to me with second thoughts before I do that.  But I think
some further consideration of this extended interpretation of paper
formats is warranted.

What do you think?

Regards,
Branden

[1] grops, grolbp, and grolj4 support '-l'.  grodvi and gxditview don't;
    I'm not certain whether they should.  grohtml and grotty aren't
    typesetting devices.[3]

[2] This appears to be due to an absent validity check.
      groff -ms -Tpdf -P -p -P letterZ
    produces no diagnostic.  I feel a strong urge to add one (a warning,
    not a fatal error).

[3] grohtml _says_ it is according to '.if t', but it is an oddball case
    with many kinds of exceptional behavior.  As with terminals,
    "orientation" is a slippery notion given resizable rendering
    windows.

signature.asc
Description: PGP signature