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

[G. Branden Robinson]

Hi Deri,

At 2023-06-09T12:26:00+0100, Deri wrote:
> On Thursday, 8 June 2023 23:33:25 BST G. Branden Robinson wrote:
> > 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.
> > :(
> 
> Be careful Branden. I know this strange behaviour is crazy, but
> because it was documented in more than 1 place it is a "feature" of
> the groff language, rather than a bug.

Maybe, but I'm dubious.  \D't' is a GNU extension; it's not documented
in CSTR #54 (1992) or CSTR #97.  One could argue that there is a general
rule that output drivers must always expect arguments to drawing escape
sequences to consist of a command selector followed by an arbitrary
number of coordinate pairs--and this appears to be a case that Bernd
Warken attempts to make in groff_out(5), though I am not certain due to
his rambling, nonstandard English.  (I think this is what his ugly
"<dummy-arg>" notation is about.)

But this is not true and it was already not true in 1981; I give you
\D'c d', where the 'c' (circle) drawing command takes only a diameter as
a parameter.  Insisting on a syntax as that which (I think) Bernd
implies is far too rigid.  The momentum for extensions to the
drawing command repertoire halted decades ago, it seems.  Nevertheless
in an attempt to minimize disruption and unportability, I added the
following advice to our Texinfo manual (with an equivalent in groff(7)).

+Unrecognized drawing commands cause GNU @code{troff} to emit a warning
+in the @code{syntax} category, but are still sent to the output device
+to support device-specific extensions.  Such commands are assumed to
+update the drawing position to the final coordinate pair in their
+argument list.  To override this assumption, wrap such a drawing command
+escape sequence with the @code{\Z} escape sequence.  @xref{Page
+Motions}.

> We have no way of knowing whether this known behaviour is actually
> used by document authors, so it may be a mistake to alter the
> behaviour now.

That's possible, but drawing escape sequences are so cumbersome to use
that it appears most document authors resort to pic(1).

Part of my change is to make grn(1) and pic(1) stop compensating for the
motion that \D't' was causing.  (Did anyone think I'd forget about
grn(1)?)

> Have you done the equivalent changes to the output drivers?

Right now this change lives only in my working copy of my "private
branch".  So far I've verified that no change to the PostScript output
driver is necessary.  I'll check dvi, lbp, lj4, pdf, and the X11 devices
as well.

I'm attaching the bundle of diffs that comprise this change and some
refactoring preliminaries.  Maybe you can tell me if my test approach
was inadequate for PostScript?

Anyway, I reiterate that this change is targeted at groff-next.  If our
luck is as bad as it has been for 1.23.0, we'll have five years to
reconsider the wisdom of it.  :-|

Regards,
Branden

signature.asc
Description: PGP signature