jwp@uwmacc.UUCP (03/27/87)
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? -- Jeff Percival (jwp@salvax1)
larry@kitty.UUCP (03/28/87)
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?"
phssra@emory.uucp (Scott R. Anderson) (01/15/88)
Does anyone know if there is a UNIX plot(5) filter for the
Tektronix 4105 graphics terminal? The latter has support for
color, so I imagine there would be a generalized plot driver
involved. I would appreciate any pointers; please mail me
any responses.
Thanks,
* Scott Robert Anderson
* ** gatech!emoryu1!phssra
* * * ** phssra@emoryu1.{bitnet,csnet}
* * * * * **
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *