I've been frustrated by groff's absolute spacing (.sp |<dist>) for
decades.

First off, <dist> is calculated from the first baseline of the
vertical spacing currently in effect when .sp |<dist> is called, not
from the top edge of the printer medium or PDF/PostScript display.
The behaviour is documented in the info manual and a workaround
is provided, but that doesn't obviate that while for tty devices
the behaviour makes sense, it doesn't for -Tps and -Tpdf, which, I
posit, are more frequently used in 2021 than tty devices, manpages
notwithstanding.

Secondly, this behaviour has consequences beyond the annoyance of
having to add -\n(.vu or -1 to absolute spacing requests.  Consider:

.ds A "Now is the time for all good men
.ds B "to come to the aid of the party.
.
.\" First half
.nf
.ps 12
.vs 24
.sp |1i-1
\*A
.ev foo
.evc 0
.vs 18 
.di bar
\*B
.di
.ev
.sp |1i-1
.in \w'\*A 'u
.bar
.in
.
.\" Second half
.sp |2i-1
.mk
\*A
.ev foo
.di baz
\*B
.di
.ev
.rt
.in \w'\*A 'u
.baz

The first half uses '.sp |dist-1' before outputting its diversion,
the second uses .mk/.rt.  In both cases, processed with -Tpdf or
-Tps, string B is higher than string A; diversions whose vertical
spacing differs from the prevailing one are not output at the
location arrived at by '.sp |dist-\n[.v]u' but rather
'.sp |dist-\n[.v-at-top-of-diversion]u'.

In a demonstration like this one, the problem is correctable by
transparently embedding the .ev foo/.evc 0 requests in the first
half inside its diversion, but in complex, trap-invoked macros
this strategy may not be desirable or even possible.  Alternative,
context-sensitive solutions are often non-evident and fussy to
implement.

I believe groff needs a dedicated request for unambiguous absolute
spacing.  One that says, "Advance from the top of the printer sheet
to the location I say and print whatever comes next right there."
The same goes for .mk/.rt.  (Preparing mom 2.5, I was surprised to
discover that .rt suffers from the same problem, one of the reasons
I've decided to bring this up.)

What say ye?  I'd like to put this in as feature request, but
there's not much point if others don't see its utility.

-- 
Peter Schaffter
https://www.schaffter.ca

Reply via email to