Kimbrough%dsg@ti-csl.CSNET (Kerry Kimbrough) (08/14/87)
I don't know why this didn't occur to me earlier, but...it didn't. Anyway, I notice that the arc parameterization admits only ellipses whose axes are parallel to the display coordinate system. I recall that ANSI X3H33 developed for the CGI standard a clever parameterization that allowed the specification of "non-parallel" ellipses. An ellipse was defined by center point and two vectors; in the case of a "parallel" ellipse, the vectors would be orthogonal and would correspond to the major/minor axes. An elliptical arc was specified by including the start/stop angles (given as values of t for the parametric form of the curve). Regrettably, I forget the precise mathematical formulation, and I no longer have my CGI phonebook to consult. "Non-parallel" ellipses crop up frequently when graphics primitives are being slapped with transformation matrices before display. The CGI formulation is neat because you just multiply the vectors by the matrix and go. The only alternative with the current PolyArc seems to be scan-converting the ellipse into a polyline or a pixmap in client code. Of course, efficiently drawing an arc from such a spec is tricky, but compared to PolyLine... Was this parameterization considered for Xv11? Was there a decision not to support "non-parallel" ellipses?
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (08/14/87)
Date: Thu, 13 Aug 87 17:38:57 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
I recall that ANSI X3H33 developed
for the CGI standard a clever parameterization that allowed the specification of
"non-parallel" ellipses.
Yes. Regrettably I also don't have my CGI leaf-press handy, but my
recollection is that non-aligned ellipses are not required of a CGI
implementation, there is an inquiry function to see if it is supported (of
course, that's true of just about everything in CGI). Also, my recollection is
that the algorithm is not published as part of CGI, and is actually owned and
patented or copyrighted by some commercial company.
Was this parameterization considered for Xv11? Was there a decision not to
support "non-parallel" ellipses?
Yes, and Yes. Depending on which camp you talk to, you will find two different
opinions. One is that the "right" way to handle this and many similar things
is to introduce an extension for general 2D coordinate transformation matrices
in graphics contexts. This gives you local coordinates, scaling, and rotation
in general (for lines, arcs, fonts, images, etc.). Along the way this can
handle non-1:1 aspect ratios, and also supports a transition to non-bitmap
scalable fonts. The other camp says "do PostScript as an extension". Some
people sit in both camps. I rather expect that both will happen, eventually.greg@CITI.UMICH.EDU (08/18/87)
I have recently been confronted with the problem of non-aligned ellipses. In writing an IGES translator, I found that IGES supported conics in any plane. This meant that a circle or some other conic could show up in any given orientation, after being transformed to 2-D. To solve the problem, I converted the IGES conic entity into multiple 3-D bezier splines, by simply transforming the control points, these became 2-D bezier splines, which were easy to rasterize, or in case of PostScript I was all done. If anyone is interested I have written an X11 extension to draw bezier splines, reply and I'll mail you a copy. -greg.