Re: Differences in `ne` and `bp` line-breaking behavior

[G. Branden Robinson]

At 2024-12-02T05:15:36+0100, onf wrote:
> page break = end line, end page
[...]
> page break = end page
> 
> Please correct me if I'm wrong.

I don't think we're to the point yet where I can say you're right or
wrong.

> Consulting the web, a 'page break' is variously defined as one of:
>   start of a new page
>   end of a page
>   end a page without filling it with text
>   end the current page and begin the next
> 
> I think the core of the problem lies in the fact that neither of us
> distinguished between a soft and hard page break.
> 
> I realize my usage hasn't been entirely consistent either, because
> a "hard" page break (.bp) implies a line break to me, and so I
> sometimes expected 'page break' to imply a line break and sometimes
> not, just as you seem to have.
> 
> Consulting the web, a 'hard page break' is defined as variations on:
>   The hard page break puts the next word at the top of a new page.
> 
> Whereas a soft page break is described as:
>    "Soft" page breaks are created by word processing and report
>    programs based on the current page length setting.
> 
> When I read "break page" in the manpage, I expect it to mean a hard
> page break, because a soft page break is automatically inserted when
> the text exceeds page length. I expect .ne to emit a hard page break
> for the same reason.
> 
> Hopefully we are on the same page now. (Pun somewhat intended.)

Maybe not, but we're getting there.  Let me throw in this wrinkle.

There's a distinction between page _ejection_ and commencement of a new
one.  I turn again to our Texinfo manual.  This is language that
originates with me, so please read it critically and point out
ambiguities.

---snip---
   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" (*note
Traps::); moreover, all but the simplest page layouts tend to have
headers and footers, or at least bear vertical margins of at least one
vee.
---end snip---

I would argue that a roff formatter doesn't really expose page ejection
as an atomic primitive.  To undertake any further typesetting
operations, a new page must begin after an ejection.  But, when there is
no more input to read, there will be no further typesetting operations,
and ejection should _not_ be followed by commencement of a new page.

Where I've encountered this point rubbing a bit is when issuing `ne`
requests that demand exactly as much space as remains before the next
page location trap.  If you get this wrong, you can wastefully forfeit
the use of the last line of formattable body text on the page.

I'll grant that some hair-splitting examples in our Texinfo manual would
probably be helpful here.

Ranging a bit further afield, the ms(7), mm(7), and doc-old packages
define their paragraphing macros to `ne` 2v as a matter of course.

This means that, with any of those packages, if you start a one-line
paragraph at the last usable line of body text on the page, it will be
deferred to the next page even though it would fit.  The paragraphing
macro doesn't know at the time that it's called that you'll have such a
short one.  This seems like an intentional compromise to avoid stranding
a line in the more common case of paragraphs longer than 2 lines.

Regards,
Branden

signature.asc
Description: PGP signature