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

[Deri]

On Friday, 9 June 2023 17:04:56 BST G. Branden Robinson wrote:
> 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.)

I have no opinion on this, as it has no bearing on whether it is wise to alter 
a feature of groff 
which has been documented for many years, but I do note the dig at a fellow 
groff contributor 
for whom english is not the first language.

> 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}.

\D't' is a valid drawing command so I can't see the relevence of this quote 
vis. a vis your proposal 
to alter troff behaviour.

> > 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).

Thank you for conceding that at least some authors will be using drawing 
commands directly, so 
this is the set of users who may be affected by this change.

> 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)?)

Why do you want to know?

It looks like what you are doing is changing a historical feature of groff, 
making changes to the 
pre-processors to produce a zero sum game, so no change for the people who use 
those 
processors, but you don't know whether it will impact documents which use 
direct drawing 
commands. In other words no one gains anything but some may discover the output 
of their 
document will change. I don't really see the wisdom in doing this.

> 
> > 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?

Unfortunately no diffs attached, so I can't see what you have changed in the 
code which 
produces the output for the drivers, but in my tests for postscript, pdf and 
dvi they each treat the 
"Dt" command as a horizontal movement as well as setting the line width. I used 
the following 
test:-

=======================================================================
========

.sp 2i
.ll 12c
Left\D't 5p'\fBIndent\fP\D'l 10p 0' Lorem ipsum dolor sit amet, consetetur 
sadipscing elitr, sed 
diam
nonumy eirmod tempor invidunt ut labore et do\%lo\%re magna ali\%quyam erat,
sed diam voluptua. Stet clita kasd gubergren, no sea takimata sanctus est.
At vero eos et accusam et justo duo do\%lo\%re et ea rebum.
.sp
Left\fBIndent\fP\D'l 10p 0' Lorem ipsum dolor sit amet, consetetur sadipscing 
elitr, sed diam
nonumy eirmod tempor invidunt ut labore et do\%lo\%re magna ali\%quyam erat,
sed diam voluptua. Stet clita kasd gubergren, no sea takimata sanctus est.
At vero eos et accusam et justo duo do\%lo\%re et ea rebum.