Re: drawing commands have no impact on diversion height

[G. Branden Robinson]

Hi Steve,

At 2023-06-08T22:18:20-0400, Steve Izma wrote:
> Thanks for pointing this out, but I think I have lost track of
> the discussions on this list about recent changes to
> documentation. The above section looks like it's from the GNU
> Troff Manual, but it's not in the version I have, which is "The
> GNU implementation of troff", edition 1.23.0. Where would I find
> the above?

It's the same document--just a later revision.  Info format doesn't
appear to include the date of revision (which is accurate to the month),
but DVI and PDF do.

Since the master branch was frozen for non-documentation changes, I've
been doing a lot of work on docs.  Almost 200 commits worth.

There are a few ways to stay on top of things:

1.  Check out groff Git master, pull regularly, and build when you want
    to have a look.[1]
2.  Browse the Git repo, if you're comfortable reading Texinfo and *roff
    sources.
3.  Read rendered documents from my Dropbox account, which I update
    regularly (generally, every time I push).[2]

> In any case, I'm sure I've not seen this discussion of DISTANCE
> being ignored within a diversion, although many times I've been
> confounded trying to control the vertical space at the beginning
> of a diversion.

The language came in in November 2021.[3]

I have no clear recollection, but my guess is that it was the fruit of
homework I did prompted by a discussion of mom(7)'s `SPACE` macro.

https://lists.gnu.org/archive/html/groff/2021-11/msg00053.html

The following exhibit produces the same output in DWB, Heirloom
Doctools, and GNU nroff:

Hello.
.br
.di XX
.sp 5v
Diversion.
.sp 5v
.di
.XX
Goodbye.

> As well, I'm not sure that this cautionary note about .sp
> addresses the issue with the .br command apparently being
> ignored. Does anyone have more insight about this?

Is it the old partially collected line diversion-inclusion land mine?

5.29 Diversions
===============
[...]
 -- Request: .di [name]
 -- Request: .da [name]
     Start collecting formatted output in a diversion called NAME.  The
     'da' request appends to a diversion called NAME, creating it if
     necessary.  If NAME already exists as an alias, the target of the
     alias is replaced or appended to; recall *note Strings::.  The
     pending output line is diverted as well.  Switching to another
     environment (with the 'ev' request) before invoking 'di' or 'da'
     avoids including any pending output line in the diversion; see
     *note Environments::.

     Invoking 'di' or 'da' without an argument stops diverting output to
     the diversion named by the most recent corresponding request.
[...]

   GNU 'troff' supports "box" requests to exclude a partially collected
line from a diversion, as this is often desirable.

 -- Request: .box [name]
 -- Request: .boxa [name]
     Divert (or append) output to NAME, similarly to the 'di' and 'da'
     requests, respectively.  Any pending output line is _not_ included
     in the diversion.  Without an argument, stop diverting output; any
     pending output line inside the diversion is discarded.
[...]

   Apart from pending output line inclusion and the request names that
populate them, boxes are handled exactly as diversions are.
[...]

> I will also experiment with the \n[.h] register to see if it keeps
> track of drawing motions that go below the baseline.

Cool.  I learned today that src/roff/troff/node.cpp goes to some trouble
to compute boundaries enclosing the output of drawing commands.  (This
is, I think, to support the "output suppression" feature that is
required by grohtml.)  If we want to reform diversions along the lines I
proposed at the beginning of this thread, I think we might already be
collecting all the information we need to update the `dn` register
accordingly.

Regards,
Branden

[1] $ git clone https://git.savannah.gnu.org/git/groff.git
[2] https://www.dropbox.com/sh/17ftu3z31couf07/AAC_9kq0ZA-Ra2ZhmZFWlLuva?dl=0
[3] 
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=f7bbcd8fae43c41bf495697f056eb02bd4b9aa8e

signature.asc
Description: PGP signature