Re: drawing commands in groff(7) (was: undiagnosed pic error)

[G. Branden Robinson]

At 2023-06-09T02:02:48-0400, Peter Schaffter wrote:
> On Thu, Jun 08, 2023, G. Branden Robinson wrote:
> > At 2023-06-08T18:19:39-0400, Steve Izma wrote:
> > > On Tue, Jun 06, 2023 at 03:07:07PM -0500, G. Branden Robinson wrote:
> > > I'm pretty sure this anomaly has been discussed on the groff list
> > > before, but I don't know of any explanation in the documentation.
> > 
> > It was there until literally days ago.  It seemed like such a subtle
> > point that I thought I might get a Savannah ticket open against it
> > and maybe even fixed for groff-next before anyone noticed.  Sorry.
> > :(
> 
> Hmm...  It might be a subtle point, but mom already compensates for
> it any time \D't n' is used to set line weight in a macro.

Ah.  Unless you compensated with \Z'\D't n'', then it sounds like I need
to sync my pending fix for Savannah #64285 with a change to the mom
macros so that no regression is perceived.

> Equally, the macros for drawing vertical rules, rectangles and
> ellipses always have their depth saved and added to \n[dn] if they are
> the last macro called before completing a diversion.  Not sure how
> germane this is but I thought I should mention it.

I think it's extremely germane to this mail from a week ago:

https://lists.gnu.org/archive/html/groff/2023-06/msg00015.html

This might explain why I've never heard of any complaints.  Only mom(7)
is careful enough to worry about this problem, and she worked around it
internally to the package.  Other *roff users have spent 40+ years
working around it in their _documents_, no doubt.

So similarly to the line thickness issue, I think we should pull this
down into the formatter and coordinate a cut-over to keep mom documents
formatting happily.  But for the broader issue, I have no time frame and
no estimates.

For the line thickness thing, please see the attached diff.

Regards,
Branden

64285.diff
Description: Text Data

signature.asc
Description: PGP signature