groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] end position of D commands


From: Ted Harding
Subject: Re: [Groff] end position of D commands
Date: Wed, 31 Oct 2001 12:56:02 -0000 (GMT)

On 31-Oct-01 Bernd Warken wrote:
> On Wed, Oct 31, 2001 at 09:04:19AM +0000, Ralph Corderoy wrote:
>> 
>> > - the polygon commands Dp and DP because they are closed (are they?)
>> 
>> So are circles and ellipses.  Polygons should leave the position at
>> the right side too.
>> 
> Other than circles and polygons, polygons have no defined right side.
> For example, take a square.  It's right side is a vertical line.  So
> there is no defined ending point.  Moreover, it will be hard for a roff
> programmer to fiddle out where an ending point on a polygon is actually
> located (for circles and ellipses, this is a single addition).
> So leaving the position for polygons untouched seems to be the easiest
> solution, but better ideas are welcome.
>>
>> That nicely splits them into `drawing' and `setting' halves.
>>
> That sounds good, but it seems to be less confusing to document the 
> positioning separately for each command than to have some vague overall
> statement somewhere.

The basic distinction is between commands which draw a parametrised
generic figure (\D'c ...', circle and \D'e' ...', ellipse; there is
no "square") and those which draw on the basis of user-supplied
coordinate increments (line, polygon and spline). At present, the
final position is the initial position plus the sum of the user-supplied
increments. In the case of \D'p ...', the polygon is drawn closed
even if the final supplied coordinate does not bring you back to
the starting point, but the final position is consistent with the
rule so the final position is the position reached at the final
user-supplied increment.

For instance, try

  This is a polygon:
  \D'p 1n 0 1n 1n 0 1n -1n 1n'\c
  So where is the endpoint?

Adopting a circle/ellipse type rule for polygons is not going to
work: whatever the x-coordinate of the right-hand side may be,
the y-coordinate is going to be depend on the polygon (assuming
that it does not have a vertical right edge, in which case the
position would be indefinite).

Note that, to make the continuation following the figure independent
of where the figure actually ends (by whatever definition), all that
is needed is to use the "\Z" request, and then follow with a motion
which starts the continuation where you want it. E.g.:

  This is a polygon:
  \Z'\D'p 1n 0 1n 1n 0 1n -1n 1n''\h'2n'
  So where is the endpoint?

which will continue the text on the same baseline, but leaving
a text-space either side of the polygon (which is 2n wide).

So it seems to me that the existing rules cover all cases
adequately (leaving aside the issue of the non-drawing "setting"
commands).

Note that you can't dodge the issue of adding up the increments
by defining the polygon as a .char: The width (\w'...') of the
.char will be the net sum of all the x-increments, and not the
maximum of the partial sums, so that, for the above,

  \w'\D'p 1n 0   1n 1n   0 1n   -1n 1n''

is 1n, while the width of what is drawn is 2n.

While it may look like an easy work-round to say (somewhat arbitrarily)
that the final relative pen position is at x = width of drawing,
y = 0 (which is at any rate consistent with circles and ellipses),
I don't think this is a good idea. If you're drawing a polygon in
the midst of text, then perhaps you'd better have a good idea of
where you get to along the way!

Best wishes to all,
Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 167 1972
Date: 31-Oct-01                                       Time: 12:56:01
------------------------------ XFMail ------------------------------

reply via email to

[Prev in Thread] Current Thread [Next in Thread]