Re: ms/mm page margins too large

[G. Branden Robinson]

Hi Robin,

I'm sorry it's taken a while for me to get back to you.  We finally got
groff 1.23.0 released and I was pretty preoccupied with that.

At 2023-06-24T02:29:26+0300, Robin Haberkorn wrote:
> I was trying to set up an ms-document with small page margins (see
> attachment), but I don't seem to get below a certain limit (especially
> on the bottom side).  In one-column mode, the bottom border is a bit
> smaller, but still larger than 1cm. I also cannot explain the spacing
> introduced by the .2C request (between BEFORE and AFTER). Build with
> 
> pdfroff -ms margins.ms >margins-ms.pdf
> 
> Does anybody understand what's going on?
> 
> I've tried something similar with mm (margins.mm), trying to set 1cm
> margins on all sides. This doesn't work as well when built with:
> 
> pdfroff -mm -P-pa4 -rW=19c -rO=1c -rL=27.7c margins.mm >margins-mm.pdf
> 
> Although, here we can at least set the page length to something
> oversized like 31c to get close to what we want. A4 has a height of
> 29.7cm, so this is also strange.
> 
> For my particular task, I will probably just switch from ms to mm. But
> it would be nice to understand why they behave this way.

There are a lot of interacting pieces, and places where things can go
wrong, in this scenario.

1.  You're using the pdfroff wrapper instead of groff directly.
2.  You're using a non-default paper size (the formatter and output
    devices assume U.S. letter paper; we have mechanisms for overriding
    this, but they require some care in usage).
3.  You're testing the margin configuration features of two different
    macro packages.

To try to reduce the complexity and narrow down where problems exist, I
constructed my own attempt at getting an ms document with 1cm margins on
all sides of the page.

I'll give you the bad news first.

A.  groff 1.22.4 requires some corrective efforts in this scenario.
B.  The groff ms package arguably does not correctly document the
    bottom footer size, and does not warn when its sign is wrong (or
    perhaps should use the absolute value of the measurement given; see
    below).

The good news is that I was able to get what looks to me like a
well-formatted ms document with 1cm margins on U.S. letter paper using
groff 1.23.

(The bottom margin still isn't a perfect 1cm, I don't think, but it
seems to be pretty close, with the slight excess size arising from the
default type size and vertical spacing not evenly dividing the printed
page area.  Adjustments to either or both of the `PS` and `VS` registers
could, I think, get the margins "perfect".  As long as there aren't any
footnotes.)

Here is my input.

.nr PO 1c
.nr LL 8.5i-\n[PO]u-1c
.nr LT \n[LT]u
.nr HM 1c
.nr FM -1c
.ds CH \" empty
.LP
.while (\n[%] < 2) \{\
a\:b\:c\:d\:e\:f\:g\:h\:i\:j\:k\:l\:m\:\
n\:o\:p\:q\:r\:s\:t\:u\:v\:w\:x\:y\:z
.\}

A few differences between your ms exhibit and mine leap out at me.

a.  I used a negative value for `FM`; since I happened to know that top
    and bottom margins are implemented using page location traps in the
    formatter, and that negative values for such traps indicate
    distances from the bottom of the page, I played a hunch and, to
    appearances, I guessed right.  I regard this as a deficiency in our
    ms(7) documentation or implementation.

b.  I didn't bother to clear the center footer string `CF` since ms(7)
    does not set it by default.

c.  I made sure to initialize the package with an `LP` call.  This is
    important, and _is_ documented.

d.  I tried to fill the page with text to make it easier to see the
    margins.

e.  I used a scaling unit when interpolating the `PO` register.  This
    isn't strictly necessary (because the `nr` request can be said to
    assume a scaling unit of "u"), but it's a good habit to get into
    when using formatter requests.

f.  I regard my hard-coding of the U.S. letter paper width (8.5i) as
    clumsy.  It would probably be better to use the strings defined in
    "papersize.tmac", which is automatically loaded by "troffrc" in
    the formatter's troff mode.

I'm attaching the foregoing document as rendered with groff 1.22.4 and
groff 1.23.0 (released 12 days ago).

The following "NEWS" item from 1.23 might provide a partial explanation
for why this new release works better.

o The s (ms) macro package now uses a default line length of 6.5 inches
  by default, resulting in 1-inch left and right margins.  When the
  "papersize.tmac" package is used by employing the "-d paper" groff(1)
  option on typesetting devices, the default page offset and line length
  are adjusted to maintain these margins.

I think next steps for troubleshooting this issue would involve:

I.    Verifying that the same results can be achieved with ISO A4 paper.

II.   Verifying that the same results can be achieved groff mm(7).

III.  Verifying that the same results can be achieved using pdfroff.

In the meantime, I'll have a look at groff ms's internals, and
historical implementations, see why the value of `FM` is not validated,
and whether it makes sense to negate it when using it to set a page
location trap.

Regards,
Branden

margins-1c-1.22.4.ps
Description: PostScript document

margins-1c-1.23.0.ps
Description: PostScript document

signature.asc
Description: PGP signature