Hi Bjarni,
On Sun Nov 23, 2025 at 9:12 PM CET, Bjarni Ingi Gislason wrote:
> On Fri, Nov 21, 2025 at 08:28:49PM +0100, onf wrote:
> > there seems to be an off by one bug in sv's geometry in groff.
> >
> > Given the input,
> > .de x
> > . br
> > ..
> > .wh 2v x
> > Lorem
> > .br
> > .sv 1v
> > ipsum
> > .br
> > dolor
> >
> > groff gives the output
> > Lorem
> > ipsum
> > dolor
> >
> > whereas both Heirloom troff and Plan 9 troff give
> > Lorem
> >
> > ipsum
> > dolor
> > [...]
>
> The bug in the 'sv' request is in the heirloom's and plan9's version.
>
> A text baseline lands exactly on the next baseline after a 1v long jump.
>
> See "Troff User's Manual" (https://troff.org/54.pdf).
Actually, CSTR #54 does not specify what should happen when sv's
argument equals distance to next trap:
.sv N
Save a contiguous vertical block of size N. If the distance to the
next trap is greater than N, N vertical space is output. No-space
mode has no effect. If this distance is less than N, no vertical
space is immediately output, but N is remembered for later output
(see os). Subsequent sv requests will overwrite any still
remembered N.
Groff's documentation explicitly defines ne's geometry as equivalent to
that of sv. However, notice the justification for ne's behavior in CSTR
#54:
.ne N
[...] If the distance D to the next trap position [...] is less
than N, a forward vertical space of size D occurs, which will
spring the trap. [...] If D < V, another line could still be
output and spring the trap. [...]
In other words, the reason that ne does nothing when .t == N is because
another line can fit in before the trap will be sprung.
However, in sv's case, what we're interested in is whether the given
SPACE can fit in before springing the trap, not some text, so in that
case we need the opposite behavior.
Also note that Plan 9 troff is a direct descendant of DWB troff and
I doubt they had any reason to change the geometry since DWB.
Cheers,
onf
