From: Alan W. I. <ir...@be...> - 2009-05-25 16:49:35
|
On 2009-05-25 00:22-0400 Hezekiah M. Carty wrote: > I would like to implement a plcircle function in PLplot. I have a few > questions before I start making commits: > > 1. Should a call to plcircle draw one circle or many? > > a) plcircle(PLINT n, PLFLT *x, PLFLT *y, PLFLT *r) > > vs > > b) plcircle(PLFLT x, PLFLT y, PLFLT r) > > I am leaning toward (b), but I am content with either option. > > 2. How should the aspect ratio of the plot be handled? My current > implementation, and I think the simplest to start with, is what is > done in example 3 - draw a set of N lines approximating a circle, > ignoring the aspect ratio. This leads to squished circles if the > x-axis and y-axis scales are unequal. I think that this is > reasonable, as otherwise the definition of a radius becomes ambiguous. > I would like to hear some other opinions on this though. > > 3. Should there be separate functions for filled vs unfilled circles? > Or should this be passed as an extra argument to plcircle? > > I can add plcircle, plarc and plellipse (or similar) functions to > PLplot, using the answers to the questions above. I can also add > support for a driver-specific circle/arc/ellipse rendering path. I > know Cairo has support for these primitives and I imagine some of the > libraries behind the other output drivers do as well. > > Comments? There are some well-known disadvantages to expanding our API. There is cost to us (e.g., documentation of the added API, propagation of the added API to all languages, changing examples to use the the new API for all languages). In addition, users generally find a small API easier to master than a large one. These disadvantages must be weighed against the general usefulness of the proposed new addition to the API for our users. The fact that both Qt (http://doc.trolltech.com/4.4/qpainterpath.html#arcTo-2) and cairo (http://cairographics.org/manual/cairo-paths.html#cairo-arc) provide arc functionality certainly supports the case for adding this API to PLplot. Furthermore, example 3 and the last page of example 16 could use this functionality. That's probably sufficient justification, but in addition I suggest you provide a few sentences stating what you expect the general use case will be along with your own particular use case(s). Assuming everybody feels the justification for this API addition is persuasive, then you might want to consider generalizing the API as much as possible. For example, if you provide a function that gives you an arc of an ellipse then everything else you have mentioned is covered by that one addition to our API. Assuming you like this idea, then I would suggest you handle aspect ratio (question 2) above by sticking to one of the pre-existing PLplot coordinate systems to specify the semimajor and semiminor axes of the ellipse. Probably you would want to use world coordinates (and similarly you would want to use world coordinates to specify the centre of the ellipse), but the choice of coordinate system really depends on how convenient those coordinates would be for your proposed use case(s), see my question above. With regard to question 1, I prefer a single elliptical arc rather than many of them since I don't see much use case for the latter. With regard to question 3, I would suggest providing an extra PLBOOL argument to fill the elliptical arc (or not). Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |