[bug #63777] explicitly document transition onto first page

[G. Branden Robinson]

Update of bug #63777 (project groff):

                  Status:               Need Info => Confirmed              
                 Summary: break before output has begun invokes top-of-page
trap => explicitly document transition onto first page

    _______________________________________________________

Follow-up Comment #3:

[comment #2 comment #2:]
> [comment #1 comment #1:]
> But I'm not sure this behavior is implied by the Texinfo documentation.  The
passage you quoted contains only one sentence on what a break _is_: "A break
interrupts filling."  But there is no pending output, so nothing to be
interrupted, so causing a break at this point logically seems like a no-op,
absent information otherwise.

A fair point.  I could add something about advancing the vertical position and
resetting the horizontal one.
 
> The Texinfo manual nowhere uses the CSTR #54 term "pseudo-page transition."

Indeed.  I don't recall it being present before, and since I don't like it,
I've never added it.

I don't think there's anything "pseudo" about it; it's a reasonable design
choice to not "be on" any page at first, in the event there turns out to be no
output to produce.  If you do so much as move to position (0,0), there _will_
be output, wasting paper, as it were.

> The text about the nl register refers to a "first page transition," but this
term is neither defined nor used anywhere else in the document; in particular,
that a break triggers it is not revealed.

It's more general than that in _groff_; _anything_ producing output will cause
the transition onto the first page.

Consider the following exhibit:


$ cat ~/src/GIT/groff/ATTIC/A.roff
.tm 1: nl=\n(nlu
A
.tm 2: nl=\n(nlu
.br \" necessary in Heirloom Doctools troff, but not in groff
.tm 3: nl=\n(nlu
.pl \n(nlu


This produces identical output on _groff_ and Heirloom Doctools _troff_, but
there is a difference.  If you take out the `br` request, the third `rm`
reports a vertical position of 0 (in both formatters), which makes sense. 
There is still plenty of room on the first output line.  But Heirloom produces
another ~65 lines of output (all blank).  Apparently there's a boundary
condition issue.  I'm already at the page length so it's "too late" to set it
to the current value and have it take effect.  I guess.

An even more minimal example produces an even more interesting disparity.

A horizontal motion of zero length is assuredly "less" output than writing one
glyph.  But it _is_ output, and I would expect it to cause a page transition
if one is in the twilight zone.  And it does.


$ cat ATTIC/h.roff 
.tm 1: nl=\n(nlu
\h'0'
.tm 2: nl=\n(nlu
.\"br \" necessary in Heirloom Doctools troff, but not in groff
.tm 3: nl=\n(nlu
.pl \n(nlu
$ nroff ATTIC/h.roff >/dev/null # groff 1.22.4
1: nl=-1u
2: nl=0u
3: nl=0u
$ ./bin/nroff ~/src/GIT/groff/ATTIC/h.roff >/dev/null # Heirloom
1: nl=-1u
2: nl=40u
3: nl=40u


I can't account for Heirloom's update of the vertical position to 40u instead
of 0.  I also don't aim to dig into it.

> (Side note: this nl paragraph is missing an end parenthesis that makes the
sentence tricky to parse.)

Fixed in my working copy--thanks!

> The .output request alludes to the behavior when it says, "This request
can't be used before the first page has started--if you get an error, simply
insert '.br' before the 'output' request."  But this is not a place a user
trying to figure out an interaction between .in and a trap would think to
look, and even then only documents the general behavior in a sideways manner.

Agreed.

> So unless I'm overlooking something in the manual (possible: I'm using
likely search terms, not reading the document top to bottom), a statement to
the effect of the one from CSTR #54 would make this clearer.

Also agreed.

I'll see if I can usefully pedagogue this issue.  ;-)


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63777>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/