Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!brl-adm!seismo!kitty!larry
From: larry@kitty.UUCP
Newsgroups: comp.unix.questions,comp.graphics
Subject: Re: Unix plot(5) oddity:  arc()
Message-ID: <1672@kitty.UUCP>
Date: Sat, 28-Mar-87 13:54:44 EST
Article-I.D.: kitty.1672
Posted: Sat Mar 28 13:54:44 1987
Date-Received: Sun, 29-Mar-87 09:39:57 EST
References: <1298@uwmacc.UUCP>
Organization: Recognition Research Corp., Clarence, NY
Lines: 43
Keywords: badly specified arcs
Xref: utgpu comp.unix.questions:1538 comp.graphics:416
Summary: Not so odd, depending upon your point of view...

In article <1298@uwmacc.UUCP>, jwp@uwmacc.UUCP (Jeffrey W Percival) writes:
> I've been fiddling around for the first time with
> the plot(1G,3X,5) graphics interface (4.3BSD, MicroVAX II)
> and I noticed a curious thing:  arcs are specifed as three
> points, rather than, say, as two points and an angle.
> Now, triplets like (center, radius, angle) always specify arcs;
> triplets like (center, point1, point2), as required by arc(3X),
> almost *never* define a circular arc.  It's like specifying
> three points for a line:  unless you compute that third
> point awfully carefully, you will have a badly specified line.
> Why is this implemented this way, and why isn't arc(3X) perceived
> as being broken?

	I have made good use of the plot(3X) and other graphics functions
under System V (should also apply to Beserkeley), and don't see a problem
with the specification for arc(3X).  Clearly, if you give arc(3X) beginning
and ending points whose radii-to-center point are NOT the same (i.e., within
one "effective pixel"), you will get a bad arc (sometimes an endless spiral,
depending upon the algorithm in the driver or filter).
	I have written my own tplot(1G) filters to convert plot(4) format
for use on the Xerox 4045 laserprinter and on some custom storage-tube
X-Y-Z displays.  In these filters, I always perform radius calculations
between the center point and the beginning and end points; if the radii
don't agree within one "effective pixel", I write a message to stderr and
abort drawing the arc.
	I don't ever recall seeing a "bad" arc specification from any
standard UNIX graphics routine (e.g., ged(1G) | gtop, pie(1G) | gtop, etc.)
or any program which I have written that generates plot(4) output.  In the
case of graphics programs that I write, I always perform calculations in
double to keep precision, and verify equal radii before writing the plot(4)
output - so I always output a good arc(3X) specification.
	So the poiint it: I don't really see a problem with arc(3X), and
don't perceive it as being broken.
	As far as WHY arc(3X) is implemented this way, I don't have a
firsthand answer, other than dealing in X-Y coordinates and integer
variables (like the radius in circle(3X)) seems to be the "design philosophy"
taken by AT&T for these routines; neither plot(4) nor gps(4) know anything
about degrees (except for textangle in gps(4)).

<>  Larry Lippman @ Recognition Research Corp., Clarence, New York
<>  UUCP:  {allegra|ames|boulder|decvax|rocksanne|watmath}!sunybcs!kitty!larry
<>  VOICE: 716/688-1231        {hplabs|ihnp4|mtune|seismo|utzoo}!/
<>  FAX:   716/741-9635 {G1,G2,G3 modes}    "Have you hugged your cat today?"