[Xr] Xr API comments

[Carl Worth]

On May 27, Bill Spitzak wrote:
 > I think some people would like to see arcs treated directly by converting 
 > them into straight lines, rather than going to an intermediate step of 
 > turning them into Bezier and then into straight lines.

For what reason?

If there were a formal Xr specification, it would guarantee that the
effect of drawing with an arc would deviate at most "tolerance" device
pixels from the geometrically correct result. Whether arcs were
handled via intermediate line segments or splines would be an
implementation detail that the user should not care about.

Or am I missing something?

Hmmm... After typing that, I'm wondering if we want to come up with
a definition for tolerance other than device pixels that would make
more sense for ridiculously high-resolution devices. Maybe tolerance
is interpreted in terms of the "standard unit size" that we use to
construct the default matrix?

 > I don't think SVG has a different drawing model, just some more operators 
 > that construct paths.

My comparison with SVG wasn't clear. What I meant was that I don't
plan to add any functions to draw geometric shapes, (XrStroke and
XrFill should be plenty).

I'm fine with adding support to make common path construction
convenient, (rectangles and circular arcs fit here), but I don't want
to go overboard.

 > It may be a good idea to support these when it is not obvious how
 > to convert them into the Xr primitives. I seem to recall SVG had
 > several calls to create conic sections, and a quadratic curve (a
 > bezier with 3 points instead of 4)

There are too many potential spline systems to add support for all of
them. Those that really want to use some other spline system will just
have to convert to cubic Bezier curves. I think circular arcs are a
special case that merit direct support.