comment #10:

> comment #7:
> > I'm a little nervous of meddling with the semantics of a
> > negative page length given the potential for interaction with
> > negative vertical drawing positions.
>
> There seem to be (at least) two ways to implement this.  When the user specifies ".pl -1", the code can either:
>
> 0 Store -1 as the page length.

I've just foreclosed this possibility (not because of this ticket, but because it was causing me headaches with trapping arithmetic).

commit a00682e9cb4070e35139f6df59130d9ce12505ce
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Thu Jul 25 15:20:55 2024 -0500

    [troff]: Enforce minimum page length.

    * src/roff/troff/div.cpp (page_length): Clamp `pl` request argument to
      the output device's vertical resolution (similarly to the way `ll` and
      `lt` behave).

    * doc/groff.texi.in (Page Layout):
    * NEWS: Document this.

> 0 Set a new flag that indicates page-length handling is to be disregarded.  Any code that compares against page length is made conditional on this flag being unset.

This remains completely feasible.

> In many cases, implementation 1 may automatically do what's desired without further code change.  But this raises your concern about interaction with negative vertical drawing positions.

I have no intention of invalidating negative vertical drawing positions.  Setting the `nl` register to `-1` to force a re-spring of a trap at vertical position 0 is well established.  There are more exotic applications like drawing an arc with its center off the page.
 

> Implementation 2 is a more invasive change.  But because it skips page-length checking altogether, it avoids the prior concern.

Not terribly invasive, I think.  This would be a property of the top-level diversion and no other formatter object I can think of.  That's also the only thing that has page location traps in the first place, so I don't foresee any problems with symbol visibility.  Possibly, all the changes that this feature needs can be made to "div.cpp".

In bug #65190 (which is a special case of this bug, applying to just the -man and -mdoc macro packages), I posted this comment, which is more relevant here, as it shows some historical demand for this feature in macro packages other than those two.

• http://lists.gnu.org/r/groff/2006-05/msg00102.html
• http://lists.gnu.org/r/groff/2008-03/msg00012.html
• http://lists.gnu.org/r/groff/2011-02/msg00054.html (thread continued in http://lists.gnu.org/r/groff/2011-03/msg00000.html)
• http://lists.gnu.org/r/groff/2020-04/msg00072.html

There may well be more, but it's not an easy thing to search because there's no historically consistent terminology for the concept.

At present I'm thinking that resolving bug #63587 will enable this well enough.

I'm a little nervous of meddling with the semantics of a negative page length given the potential for interaction with negative vertical drawing positions.

For one thing, one might reasonably draw a geometric primitive, like an arc, from a negative vertical (or horizontal, for that matter) drawing position.

As #63587 proposes, we could fix the built-in, read-only register to "INT_MAX" instead of ten thousand.

We could then migrate (some of) our macro packages to support continuous rendering under this approach rather than the current one, which has caused other problems.  See bug #57665 and bug #63960.

Certainly, doing

.pl \n[.R]u

lays a trap for the document/macro package author if they unthinkingly do something like

.pl +1v

somewhere, as groff man(7) and mdoc(7) do.  This will cause an arithmetic overflow error.

However, incrementing the page length appears to be an uncommon operation.

$ git grep 'pl +'
contrib/hdtbl/hdmisc.tmac:.    pl +1            \"      without arg increase page length by 1v
contrib/hdtbl/hdmisc.tmac:.    pl +\\$1         \"      otherwise use \\$1
doc/groff.texi:.pl +1v
tmac/an.tmac:.    pl +(\\n[an-amount]u - \\n[.t]u + 1v)
tmac/an.tmac:.    if ((\\n[.p] - \\n[nl]) <= \\n[.V]) .pl +1v
tmac/an.tmac:.    pl +1v
tmac/an.tmac:.      pl +1v
tmac/an.tmac:.  ie \\n[cR] .pl +1v
tmac/an.tmac:.    pl +1v
tmac/an.tmac:.  if \\n[cR] .pl +1v
tmac/mdoc/doc-common:.    pl +(\n[doc-amount]u - \n[.t]u + 1v)
tmac/mdoc/doc-common:.  ie \n[cR] .pl +1v
tmac/mdoc/doc-common:.    pl +1v
tmac/mdoc/doc-common:.    if ((\n[.p] - \n[nl]) <= \n[.V]) .pl +1v
tmac/mdoc/doc-common:.    pl +1v
tmac/mdoc/doc-common:.      pl +1v

I expect the man(7) and mdoc(7) instances to go away when this ticket is resolved, and hdtbl.tmac needs to be audited on this point.  (I think it targets only HTML output, where the meaning of "page length" is not obvious.)

In principle, this approach could be adapted to conventional macro packages; pending footnotes could be flushed at appropriate times (the end of a section, chapter, or document).

The above also suggests that we have an example to review in our Texinfo manual, if/when this ticket is addressed.

comment #4:

> I guess would only add that the zero-sized vertical margins
> aren't anything special that the `an` package does; these are
> the margins inherited from troff's defaults.

Good point; the -man macros to handle this are really just dealing with things like calls to .ne and .bp.

But even .ne wouldn't need any special handling if native roff allowed conceptually setting the page length to infinity: then all .ne calls would turn into no-ops, since there would by definition always be room on the current page.

original submission:

> groff could provide a new, dedicated tmac file for this task
> and properly document its inclusion and use.  The existing
> macros in an.tmac could be leveraged for this if they're
> suitable for general use.

My guess now is that they aren't.  As I understand it, in contrast to the one-long-page system the Texinfo manual gives an example of, the -man macros set top and bottom margins of internal pages to 0, so that, even though nroff outputs multiple "pages," the breaks between them are invisible, effectively looking like one long page.

This is fine in the -man language, which doesn't support footnotes.  But it's unclear how this could be generalized to work with the full-service macro packages, most of which do include mechanisms to render footnotes at the bottom of the page.  In the one-long-page case, this pushes footnotes to the end of the output.  But for multiple pages with invisible page breaks, this would effectively put footnotes at random-seeming places in the middle of the text.

This isn't to say that the problem is insurmountable, only that a straightforward adaptation of the -man system probably won't cover the complexities of existing macro packages or unfettered roff.

An interim solution might be to beef up the documentation about the -man method.  Providing a fully functional example for the .em method and only a terse summary, in a footnote, of the -man one, implies the former is the preferred one.

Arguably, the latter technique is merely a clever combination of the building blocks already documented in the Texinfo manual, and the manual certainly can't and shouldn't be expected to document every novel combination of primitives.  But the same argument could apply to the .em example as well; usage of .em itself is already illustrated in a prior example, so the second example exists only to show a way to do continuous rendering, while introducing no new groff concepts.