Hi Larry,

At 2026-05-23T09:22:01-0400, kollar wrote:
> G. Branden Robinson <[email protected]> wrote:
> > Another thing that might help is to have the source document record
> > where the right margin is by having the formatter compute it and
> > then issue it as a "trout" comment for collection and interpretation
> > by your filter.  This could be more reliable than doing it yourself
> > in AWK, and almost certainly preferable to doing arithmetic in
> > sed(1).[A]
> > 
> > Sketch:
> > 
> > $ printf '.po 1i\n.in 2i\n.ll 3i\n.nr right-margin 
> > \\n[.o]+\\n[.i]+\\n[.l]\n\\!# right-margin=\\n[right-margin]\n' \
> >  | groff -Z
> > x T ps
> > x res 72000 1 1
> > x init
> > p1
> > # right-margin=432000
> > x trailer
> > V792000
> > x stop
> 
> I think `\\n[.o]+\\n[.l]` would be sufficient to calculate the right
> margin.  The `.in` request indents relative to the page offset, so it
> could be safely ignored outside a corner case like this,

Ahh, you're right.  My memory failed me!

groff's Texinfo manual has long featured a diagram illustrating the
anatomy of the output line.

(Would anyone like to recreate this diagram in pic(1) so that we can
use tpic to embed it it using `@iftex`?)

https://www.gnu.org/software/groff/manual/groff.html.node/Line-Layout.html

> where the `.po` and `.ll` requests have not been defined yet.

Here I'll attempt a correction despite having just pantsed myself.

These requests are defined by default, because, being requests, they're
internal to the formatter logic.  You can delete them, but unless you
use a GNU extension to alias them first, they are then gone forever (for
the lifetime of the troff process).

Further, default values of the page offset and line length are
initialized at formatter startup per the output device's "DESC" file.

We can verify the foregoing claims by running troff(1) directly, using
the GNU `-R` option to suppress the reading of start up files.  If we
also specify no operands and no `-m` options, we get the formatter's
pristine default configuration, naked as the day it was born (because it
just was).

$ troff -R -T ps <<EOF
.pm po
.if d po .tm po is defined
.pm ll
.if d ll .tm ll is defined
.pnr .l
.pnr .o
EOF
po is defined
ll is defined
.l      468000  0
.o      72000   0

(That's groff 1.24 output; in the forthcoming groff 1.25, the `pnr`
request will no longer report a number format ("0") for read-only
registers, because the number format of a read-only register cannot be
altered, and because if the read-only register is not string-valued, its
number format is always "0".)

$ printf '.pnr .l\n.pnr .o\n' | ./build/test-groff
.l      468000
.o      72000

The foregoing tells us that the names `po` and `ll` are defined but have
no reportable contents, which makes sense because they're requests,
implemented in C++ logic instead of *roff, and that the page offset and
line length are initialized as shown.

> But if a negative `.in` request were to push text *into* the left
> margin, it would be best to not mess with that line at all.

For practical purposes, I suspect you're right, because your mission in
this thread is to "square up" (rectangularize) the page's text block
with respect to its letter glyphs, treating trailing punctuation as a
sort of adornment.  That seems like something typographers would indeed
have gotten up to in years past, though I don't know of examples.  If
someone defines an indentation amount that backs up into the left margin
(page offset), they're breaking the rectangle anyway, presumably for a
deliberate purpose.

...but, if you _did_ want to take the indentation amount into account
_only if it were negative_, GNU troff has an extension to the numeric
expression syntax that can help.

.nr right-margin (\n[.o] + (\n[.i] <? 0) + \n[.l])

groff_diff(7):
   Numeric expressions
     GNU troff permits spaces in a numeric expression within
     parentheses, and offers three new operators.

     e1>?e2  Interpolate the greater of expressions e1 and e2.

     e1<?e2  Interpolate the lesser of expressions e1 and e2.
...

> I hope to have a chance to work on this next week, once Daughter
> Dearest is finished with school stuff (she’s a teacher) and I won’t be
> watching her kids all day (most days, at least).

Cool.  Good luck--with the kids _and_ the postprocessor!  :)

Regards,
Branden

Attachment: signature.asc
Description: PGP signature

Reply via email to