Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!uwvax!rutgers!ames!ucbcad!ucbvax!ti-csl.CSNET!Kimbrough%dsg
From: Kimbrough%dsg@ti-csl.CSNET (Kerry Kimbrough)
Newsgroups: comp.windows.x
Subject: Xv11, PolyArc
Message-ID: <2764881537-775490@Sierra>
Date: Thu, 13-Aug-87 18:38:57 EDT
Article-I.D.: Sierra.2764881537-775490
Posted: Thu Aug 13 18:38:57 1987
Date-Received: Sat, 15-Aug-87 11:40:32 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 22

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?