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

[Deri]

First attempt truncated, try this. :-(

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.


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


The first paragraph has a gap after the first word caused by the \D't' escape, 
the second paragraph does not, apart from that they are identical. The "r," in 
the word "elitr," in the first line is subject to kerning so troff outputs a 
absolute horizontal position (an H command) before the comma to allow for the 
kern adjustment. Troff and the output driver have to keep the current 
horizontal position in step in order for the absolute horizontal position to 
be correct.


If you could run the above on your private groff noting if the position of the 
comma is correct. If it is not then your statement about no change required to 
the output drivers is incorrect.


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


So you don't intend to release the change to git master after 1.23.0 is 
released. If you do anyone compiling from git would be affected right away.


Cheers 


Deri


> Regards,
> Branden