[Groff] end position of D commands

[Bernd Warken]

On Tue, Oct 30, 2001 at 08:04:48PM -0000, Ted Harding wrote:
> 
> By the way: Up to now, all the "\D" commands generate movement
> according to their numerical parameters, even if the meaning
> of the command does not imply movement (and "\D'f n'" is an example,
> requiring an additional "\D'f n'\h'-nu'" to undo the motion;
> likewise "\D't n'").
> 
> a) Is this "feature" retained for the new extensions?
> 
> b) I have always found this inconvenient except for those "\D"
>    commands which really do draw, i.e. imply real "movement of
>    the pen". Is this the moment to re-think the question?
> 
The info file and the man page document a problem with setting the
position of the graphical pointer on the printout after the execution
of such commands.  This specification is ugly, incomplete, and differs
from the groff source (being buggy anyway).

The classical troff manual documents that the final position of
circles and ellipses is at the right side.  The overall rule for the
other commands is to position at the end.  This makes sense for the
classical case because there were only 3 other commands left :
D~ (B-spline), Da (arc), and Dl (line).

groff has added new drawing requests/commands.  Unfortunately, the
groff documentation says that the classical end-positioning rule had
to applied to all groff additions as well because "UNIX troff"
(whatever that might be) used the same rule "though it produces an
ugly result" in some cases.  A better description would be "absolutely
brain-damaged".

The groff source is so buggy that not even the classical case is
followed.  So compatibility isn't an issue here anyway.

I propose to implement the classical compatibility (including the
filled cirles and ellipses) and forget about the "UNIX troff" and the
corresponding documentation.

Then the following commands (groff additions) will not change the
position :

- the setting commands (no drawing) : Df, DF, Dt
- the polygon commands Dp and DP because they are closed (are they?)

Gracefully, the documentation says that the problem is not important
because the pic generated code does not depend on it (by absolute
repositioning?), so it won't hurt to change it.

Bernd