Re: device-dependent warnings

[Dave Kemper]

On 5/8/23, Alejandro Colomar <alx.manpages@gmail.com> wrote:
> I couldn't notice the non-infiniteness.  See the following session.

I'm not sure what you thought that test was measuring, but I'm pretty
sure it's not what it was actually measuring.

First, the man macros don't set their page length to INT_MAX.  This
was a hypothetical future change Branden proposed, which was clear in
the original context but had been edited out of the conversation by
this point, in part because the mention of INT_MAX itself was in a
footnote, physically separated from the relevant context even in the
original message floating that proposal (see
http://lists.gnu.org/r/groff/2023-05/msg00033.html).  So the test was,
if anything, testing a potential future -man implementation.

Second, the maximum page length of a document that groff can store is
INT_MAX *basic units*.  But, nonintuitively, a basic unit on a
terminal is not a line.  So looking at what happens at the INT_MAXth
*line* is not telling you anything about what's happening where the
page break actually occurs.

(I can already hear the questions.  "Why is the terminal basic unit
not a line?  What IS it then?"  The answers are:

1.  I have no idea.
2.  That makes no difference to man page authors.

You're unsatisfied by these.  I'll elaborate.

1.  Well, I still have no idea, so there's no more I can say about that.
2.  One of the goals of the -man macros is to shield man page authors
from having to worry about low-level roff implementation details, so
that they can focus on the content of the page.  But if you must know,
look at the \n[.V] register in low-level roff, which the 1.22.4 manual
describes as the "number of basic units per vertical unit of output
device resolution."  It could be different for every device, and it's
easy to see the difference between the PostScript device and the
terminal one:

$ echo '.tm \\n[.V] is \n[.V]' | groff
\n[.V] is 1
$ echo '.tm \\n[.V] is \n[.V]' | nroff
\n[.V] is 40

So an INT_MAX-length terminal page would be INT_MAX / \n[.V] lines
long.  Though probably not even that, because a defensively coded
"infinite" page length would be something like \n[INT_MAX]-2v.)

And lest you're tempted to keep your test around for the day Branden
does change -man's continuous rendering methodology, I bet that's when
things won't go as you'd hoped.  Long man pages currently have many
"page" breaks, but the package goes through some calisthenics to make
these breaks invisible (a trick that cannot be adopted by macro
packages that also support things that are placed relative to page
bottoms, like footnotes).  But these calisthenics have the occasional
ill side effect, especially when tables are involved, so I expect
they'll be removed once man page continuous rendering is retooled in
the way Branden imagines.  However, once man pages expect to not have
ANY internal page breaks, a hypothetical INT_MAX/\n[.V]-line page will
likely go awry.  If I thought that were remotely a real-world concern,
I'd push back on http://savannah.gnu.org/bugs/?61453#comment7.