Carl Worth <[EMAIL PROTECTED]> writes:
> On Dec 1, Owen Taylor wrote:
> > - No convenience function for circular arcs.
>
> I want to add something here. I'd like some input on what the
> interface should look like. I would have loved to have a nice clean
> function named XrArcTo that draws a circular arc from the current
> point to a specified point, (which becomes the new current
> point). This would fit in nicely with XrMoveTo, XrLineTo,
> XrCurveTo. But I haven't found a good way to do this.
>
> I've reviewed arc support in several 2D graphics systems and it seems
> to me that PostScript takes the right approach[*].
I think it makes a lot of sense to follow postscript, since the
rest of the API is tracking postscript as well. The need for
an explicit "negative" variant really comes from the fact that
the direction in which the path is traversed matters for paths,
but not for standalone primitives.
> So, I propose the following functions:
>
> XrArc (xc, yc, radius, angle1, angle2); /* angle 2 > angle1 */
> XrArcNegative (xc, yc, radius, angle1, angle2); /* angle 2 < angle1 */
>
> XrArcTo (x1, y1, x2, y2, radius);
>
> These are all circular arcs, (it seems elliptical arcs should be easy
> enough to generate with XrScale and XrRotate for those who really want
> them).
>
> Open questions:
>
> Would XrArcTangent be a better name than XrArcTo?
_Something_ would definitely be better than XrArcTo :-).
(XrArcTo would be better as XrArcTO since I think the O is
from 'Out', but that would still be a pretty bad name for
anybody but someone familiar with postscript)
XrArcTangent isn't bad. I might suggest XrArcTangents
just so it doesn't sound like the trig function.
XrTangentArc would be another possibility, though it does
move it far away in API documentation.
> PostScript arcto returns the computed values of the arc endpoints. How
> important is this? Any suggestions for how to do this in the Xr API.
The right translation of the postscript interface would pretty clearly be:
XrArcTangents (x1, y1, x2, y2, radius, &xend1, ¥d1, &xend2, ¥d2)
But that's overbudget for parameters and having to tack four NULLs
onto the end of the call isn't pleasant.
It's not clear if these output results are generally useful;
the first 5-10 examples I found of arcto usage in a google search
all were places where the user would have been happer with
'arct' - either they leaked stuff onto the stack, or they
did something equivalent to 'arcto 4 {pop} repeat'.
Maybe people assume they should be using arcto in analogy
to curveto.
My guess - skip them; they are clearly a pain for most usages
so a separate function would be better, and that can be
added later.
(I think the right separate function wouldn't be a function
that draws and returns the end points, but simply one
that computes them; the user can then call XrArc if they
want to draw at the same time.)
> Also, regardless of the parameterization, all Xr functions must be
> able to approximate geometry within a user-specified error bound. So,
> to implement this, I would like a function that accepts the arc
> parameters and the error bound and that returns the number of cubic
> bezier splines needed to approximate the arc within that error. Could
> anyone easily provide something like that?
Not offhand; I spent some time over the Thanksgiving holiday
fooling around with the relevant math, but didn't come with
anything immediately useable. Probably better to find some
canned solution to borrow.
> PS. Oh, and how about a convenience function for rectangles? I think
> XrRectangle should add a rectangle to the path, (convenience function
> for a MoveTo and four LineTo's). I don't see the need now to implement
> functions like PostScript's rectstroke/rectfill, (any such
> optimization functions can be added later if necessary).
Sounds plausible to me.
Regards,
Owen
_______________________________________________
Render mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/render
