Re: Proposed GNU troff behavior change: require end-of-input macros to exit

[G. Branden Robinson]

Hi Doug,

At 2023-12-09T09:26:16-0500, Douglas McIlroy wrote:
> > For historical reasons (and for compatibility with AT&T 'troff'),
> > the end macro exits as soon as it causes a page break and
> > no remaining data is in the partially collected line.
> 
> This isn't the only anomalous behavior at the end of a document. Since
> day one, troff has occasionally emitted a blank page at the end. I
> believe this is because a new page is triggered when the previous page
> is filled rather than when some output needs somewhere to go. A
> document that exactly fills the last page thus gets an extra page.

Right.  When a line of output is "finished" and sent to the device
(device-independent output is prepared for it), the vertical position
advances by one vee, and, (in groff, if vertical position traps are not
disabled,) any visible vertical position traps planted between the
previous text baseline and the new one are sprung.[1]  If one of these
traps is what I term "the implicit page trap"[2], then the page is
ejected and a new one started.

Here is how I try to present this information in our Texinfo manual and
roff(7).

     Vertical spacing has an impact on page‐breaking decisions.
     Generally, when a break occurs, the formatter moves the drawing
     position to the next text baseline automatically.  If the formatter
     were already writing to the last line that would fit on the page,
     advancing by one vee would place the next text baseline off the
     page.  Rather than let that happen, roff formatters instruct the
     output driver to eject the page, start a new one, and again set the
     drawing position to one vee below the page top; this is a page
     break.

     When the last line of input text corresponds to the last output
     line that fits on the page, the break caused by the end of input
     will also break the page, producing a useless blank one.  Macro
     packages keep users from having to confront this difficulty by
     setting “traps”; moreover, all but the simplest page layouts tend
     to have headers and footers, or at least bear vertical margins
     larger than one vee.

Of itself, I don't think this procedure is closely coupled with
end-of-input macro handling.

> Before jumping for a special fix for .em, you might like to consider
> the more general question of how a page gets initiated and/or when a
> trap gets sprung (upon reaching it or upon passing it?).

I've been trying to, and I haven't come up with any other ideas, hence
mooting it on the list.  :)

> Then .em
> might not need so much special pleading.
> 
> In regard to the narrow issue of .em, what alternate
> fixes have you considered? For example, instead of
> exiting, .em might be required to do .rm em.

You mean that we might require the macro called by the `em` request to
delete the `em` request itself (or whatever the user renamed it to)?

> Or the removal could be done automatically when .em is invoked. Under
> either regime, a user could even arrange for .em to be reinstated to
> accomplish a second coming--er, ending.

It seems like this would imply looping on "if end-of-input macro
defined" at the end of input.  That seems similar to my proposal; either
one could lead to groff "hanging" (blocking while trying to read from
stdin) if the user doesn't follow the rules.

One of the reasons my proposal has the shape it does is because it is so
hard to explain.

[groff.texi from Git HEAD]

--snip--
   (1) While processing an end-of-input macro, the formatter assumes
that the next page break must be the last; it goes into "sudden death
overtime".
--end snip--

Any time I have to resort to a sports metaphor (and possibly a
U.S.-centric one at that) to explain a technical point, I treat that as
an indicator either that I'm being too whimsical or that the system in
question is too baroque.

Regards,
Branden

[1] With mysterious exceptions that seem to be widely shared among
    *roffs.  In a nutshell, implementations seem to assume that only one
    vertical position between the current and next baselines will have
    traps planted.  This is not the same thing as having one trap hide
    others at the _same_ vertical position, nor the same thing as
    vertical position traps not being able to be sprung while a
    trap-called macro is being interpreted.

    https://savannah.gnu.org/bugs/?56499

[2] 
https://www.gnu.org/software/groff/manual/groff.html.node/The-Implicit-Page-Trap.html

signature.asc
Description: PGP signature