On Thursday, 20 November 2025 17:43:11 GMT onf wrote:
> Hi all,
>
> I've recently discovered that groff's output drivers grodvi, grolj4, and
> grolbp support an additional drawing command \D'R'. I notice from the
> respective manpages that the reason for its addition seems to be lack of
> support for other drawing commands by the respective devices.
>
> With that said, I've been wondering why it's device-specific and not
> also supported by grops and gropdf despite being easy to implement in
> PostScript and PDF?
>
> It seems like a useful command to replace the old \l (that uses \[ru])
> since \D'l' is specified as having round line endings by default.
>
> Cheers,
> onf
Hi onf,
There is a difference between how grops and gropdf handle an unknown graphic D
command (such as DR), not intentional. The groff_out man page says:-
"Unknown D commands are assumed to be device-specific. Its arguments are
parsed as strings; the whole information is then sent to the postprocessor."
I took this to mean that troff did nothing except parse the arguments to \D'R
x y' and convert the two values to basic units (u) and write it to the grout
file. However, it seems (from empirical observation of the grout output) troff
adjusts its notion of the current xy position by the values it parses. This
can be seen by including a \Z'' after the drawing command which causes troff
to output an "H" command in the grout and the value includes the x value of
the DR command.
grops does the same xy adjustment on receiving an unknown drawing command -
summing the even parameters to produce a new x position and doing the same for
odd numbered parameters for the y position.
gropdf does not do this, it just ignores the grout command, as it does with
any other grout line it does not understand. This is why the output from
gropdf differs from grops if any unrecognised drawing command is encountered.
This is the little test script I used to investigate:-
==================================================================
\M[skyblue]\m[steelblue]Deri \D'R 1i 1i' James \Z@\h'2n'not@is good.
.br
And I can prove it
.sp 2i
Deri \D'X 1i 1i -1i -1i' James \Z@\h'2n'not@is good.
.br
And I can prove it
==================================================================
The attached patch fixes this, so gropdf behaves the same as its brother
devices, (with the bonus it now supports \D'R x y' and \D'r x y' - unfilled).
There is a difference because grodvi uses the current text colour \m[] whereas
gropdf uses the current fill colour \M[] in line with the other graphic
primitives which have stroke and fill versions.
Cheers
Deri
diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index d0da52c42..772ff1a0f 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -4233,6 +4233,35 @@ sub do_D
$poschg=1;
}
+ elsif ($Dcmd eq 'R' or $Dcmd eq 'r')
+ {
+ $par=substr($par,1);
+ my (@p)=split(' ',$par);
+
+ foreach my $p (@p) { $p/=$unitwidth; }
+ $stream.=PutXY($xpos,$ypos)." $p[0] -$p[1] re ";
+ $xpos+=$p[0];
+ $ypos+=$p[1];
+
+ $stream.=(($Dcmd eq 'R')?"f":"s")."\n";
+ $poschg=1;
+ }
+ else
+ {
+ $par=substr($par,1);
+ my (@p)=split(' ',$par);
+
+ foreach my $p (@p) { $p/=$unitwidth; }
+
+ for (my $i=0; $i < $#p; $i+=2)
+ {
+ $xpos+=($p[$i]);
+ $ypos+=defined($p[$i+1])?$p[$i+1]:0; # incase params aren't pairs!!
+ }
+
+ $poschg=1;
+ Warn("unrecognised drawing command '$Dcmd'");
+ }
}
sub deg
