Follow-up Comment #17, bug #50770 (group groff): Hi Dave,
I'll give Deri some time to rebut you if he would like to, but in the
meantime...
At 2024-09-13T20:06:05-0400, Dave wrote:
> > Any change would also have to consider the impact if PSPIC is used
> > within a diversion, i.e. not at the point it is actually being
> > output to the page.
>
> AIUI, within a diversion, .ne is effectively a no-op, so changing the
> value given to .ne should not affect this case either.
Well...sort of. There is no special logic in the `ne` request handler
to do nothing if the formatter is currently processing a diversion.
void need_space()
{
vunits n;
if (!has_arg() || !get_vunits(&n, 'v'))
n = curenv->get_vertical_spacing();
while (!tok.is_newline() && !tok.is_eof())
tok.next();
curdiv->need(n);
tok.next();
}
However, you might not be wrong in a practical sense.
5.28.1.3 Diversion Traps
........................
A diversion is not formatted in the context of a page, so it lacks page
location traps; instead it can have a "diversion trap". There can exist
at most one such vertical position trap per diversion.
-- Request: .dt [dist name]
Set a trap _within_ a diversion at location DIST, which is
interpreted relative to diversion rather than page boundaries. If
invoked with fewer than two arguments, any diversion trap in the
current diversion is removed. The register '.t' works within
diversions. It is an error to invoke 'dt' in the top-level
diversion. *Note Diversions::.
I haven't yet used a diversion trap in anger, but what I have twigged is
that, as a rule, we want diversion content to be closely cropped, if you
will. It should have no negative space around its formatted elements
(glyphs and geometric figures). Or, in this case, an opaque inclusion
of material inserted via a device extension and which occupies space in
the top-level diversion (if the diversion is ever called for).
At first blush that would seem to argue for your proposal...I think?
It is possible that it's not a good idea to use `PSPIC` inside a
diversion for other reasons, at least not directly. It might be one of
those cases where you want to "bubble it up" via the `\!` escape
sequence,[1][2] and call the macro only once you truly are formatting
the page (a.k.a. top-level diversion).
It does seem to me that I should be able to draw a horizontal rule 1u
(or even 0u?) below a `PSPIC`-included image without having to do a
reverse vertical motion first. I haven't played with it much, so if
that's not the status quo, that feels like a bug to me.
I will also say that I am emphatically not wedded to the immutability of
the "grout" that GNU troff emits for a given input. I have several
complaints about it, from its esthetic of whitespace usage to its
frequent and seemingly redundant resets of the drawing position with
absolute positioning commands. The former I am confident I can solve
(though it is not a matter of urgency); the latter seems trickier.
Bug #64484 and bug #66187 have gotten me as deep into the innards of the
formatter as I have yet explored, and I am consistently presented with
mixtures of mystery and code smells that I am challenged to distinguish.
I'm going to miss my self-imposed "freeze the formatter in early
September" deadline. Time to start abandoning goals for groff 1.24. :(
Regards,
Branden
[1] or `output` request
[2] I'll confess that it was the example of page breaks in boxed tables
that finally lit the bulb over my head with respect to this
technique. See tbl(1), section "Limitations".
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?50770>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
