From: Hezekiah M. C. <hez...@us...> - 2009-05-25 04:22:33
|
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? Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science |
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 __________________________ |
From: Robert P. <rob...@jk...> - 2009-05-26 07:05:04
|
Alan W. Irwin schrieb: > [...] 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. Let me mention that example x32c.c shows a use case for not using world coordinates: drawing an undistorted circle as a marker. Robert |
From: Alan W. I. <ir...@be...> - 2009-05-26 15:58:42
|
On 2009-05-26 09:02+0200 Robert Pollak wrote: > Alan W. Irwin schrieb: >> [...] 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. > > Let me mention that example x32c.c shows a use case for not using world > coordinates: drawing an undistorted circle as a marker. Robert, I am glad you brought this up since there is an important distinction between circular symbols (which, as you suggest, must remain circular regardless of aspect ratio), and a geometrical figure (whose axis coordinates will probably be world coordinates). Hez, can you confirm your intended use case was for a geometrical figure rather than a symbol? Clearly, in the case of example 32 a circular symbol was meant. examples/python/test_circle.py contains a number non-unicode and unicode ways of generating such symbols. Example 1 and Example 6 show additional methods of generating circular symbols. I suggest example 32 be simplified to use one of those methods rather than using the local "plcircle" function that is currently implemented in x32c.c to duplicate that already-existing PLplot core functionality for generating circular symbols. 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 __________________________ |
From: Robert P. <rob...@jk...> - 2009-05-27 07:38:45
Attachments:
use-plpoin-in-x32.patch
|
Alan W. Irwin schrieb: [...] > Clearly, in the case of example 32 a circular symbol was meant. > examples/python/test_circle.py contains a number non-unicode and unicode > ways of generating such symbols. Example 1 and Example 6 show additional > methods of generating circular symbols. I suggest example 32 be simplified > to use one of those methods rather than using the local "plcircle" function > that is currently implemented in x32c.c to duplicate that already-existing > PLplot core functionality for generating circular symbols. I agree. Here is the patch to use plpoin as in examples 1 and 6. What gets lost, though, is the demonstration of how to get the axis ratio for drawing custom symbols. Robert |
From: Andrew R. <and...@us...> - 2009-05-27 08:23:25
|
On Wed, May 27, 2009 at 09:36:49AM +0200, Robert Pollak wrote: > Alan W. Irwin schrieb: > [...] > > Clearly, in the case of example 32 a circular symbol was meant. > > examples/python/test_circle.py contains a number non-unicode and unicode > > ways of generating such symbols. Example 1 and Example 6 show additional > > methods of generating circular symbols. I suggest example 32 be simplified > > to use one of those methods rather than using the local "plcircle" function > > that is currently implemented in x32c.c to duplicate that already-existing > > PLplot core functionality for generating circular symbols. > > I agree. Here is the patch to use plpoin as in examples 1 and 6. > > What gets lost, though, is the demonstration of how to get the axis > ratio for drawing custom symbols. I think an example of how to get the axis ratio is useful. It is not uncommon to want to do this to ensure the aspect ratio of drawn components (e.g. circles, squares) is correct. Another example I often have is to get the direction of arrows correct when the axis scales are different. Perhaps this would be a better example of this particular technique? Andrew |
From: Alan W. I. <ir...@be...> - 2009-05-27 19:20:54
|
On 2009-05-27 09:36+0200 Robert Pollak wrote: > Alan W. Irwin schrieb: > [...] >> Clearly, in the case of example 32 a circular symbol was meant. >> examples/python/test_circle.py contains a number non-unicode and unicode >> ways of generating such symbols. Example 1 and Example 6 show additional >> methods of generating circular symbols. I suggest example 32 be simplified >> to use one of those methods rather than using the local "plcircle" function >> that is currently implemented in x32c.c to duplicate that already-existing >> PLplot core functionality for generating circular symbols. > > I agree. Here is the patch to use plpoin as in examples 1 and 6. Hi Robert: Thanks, for the patch. I have applied it with a change to use a larger circle rather than the smallest one (revision 10007). For my eyes this changes the outliers from an annoying dot on the plot to something that is clearly visible. > What gets lost, though, is the demonstration of how to get the axis > ratio for drawing custom symbols. This idea should obviously be reserved for geometrical figures (as opposed to pure symbols which by definition always appear the same regardless of world coordinates or aspect ratio). Assuming Hez's use case for his suggested new API is for a geometrical arc attached to world coordinates as opposed to just a symbol, a new example that uses that new API might be a good opportunity to demonstrate the axis ratio technique just removed from example 32. The rest of this post is directed to Andrew. Hi Andrew: The existing example 22 might be another possibility for demonstrating the axis ratio technique, but in that case I think there is also a possibility to moving to pure symbols which leads to a further question. What do you think of the idea of changing plvect to use unicode fonts internally to draw the required arrows? See example 23 for a large selection of such arrow possibilities in the unicode world. Of course, for devices that are not unicode aware you would internally fall back to the present drawn arrows (suitably scaled so the results are independent of world coordinates and aspect ratio). Or you could ignore unicode altogether and use the suggested fallback for all devices regardless of whether they are unicode or not. It appears from your previous post in this thread that axis scaling is required for certain uses of the current plvect. That step should no longer be necessary if you changed plvect to generate pure symbol arrows as outlined above. 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 __________________________ |
From: Hezekiah M. C. <hez...@us...> - 2009-06-03 19:27:44
|
On Mon, May 25, 2009 at 12:49 PM, Alan W. Irwin <ir...@be...> wrote: > 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. <cut> > ... 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). My personal use cases are currently marking satellite radar footprints and drawing custom diagrams/shapes on plots. I am currently doing this using either plline or plfill, similar to how circles are drawn in the examples. The main drawback I have experienced with this method is that drawing an arc as a series of line segments or as a filled polygon can have a large impact on the file size of vector output (PS, PDF). To clarify on a question asked later in the thread, I intend this function to be for plotting another set of geometric shapes, not necessarily something which will always look like a circle. If an example is added for plarc then aspect-ratio correction would probably be a nice page to include in that example. > Assuming everybody feels the justification for this API addition is > persuasive, then you might want to consider generalizing the API as much as > possible. Based on this, I reworked the (only) function prototype so that it currently looks like this: void c_plarc(PLFLT x, PLFLT y, PLFLT a, PLFLT b, PLFLT angle1, PLFLT angle2, PLFLT rotation, PLBOOL fill); where: x, y - center of the arc a and b - semimajor and semiminor axes angle1, angle2 - start and end angles for the arc rotation - rotation of the arc about (x, y) fill - should the arc be filled? Angles are all provided in degrees. I have an initial "raw" implementation in place for devices which do not support an arc primitive. This uses plline and plfill internally. It modified example 3 locally to use plarc and the results seem reasonably accurate. I have a started a Cairo implementation but I don't have the coordinate transformation correct from world coordinates to Cairo coordinates. I will ask about that in a separate email. Thank you to everyone who made comments during my extended delay on getting back to this thread. Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science |
From: Alan W. I. <ir...@be...> - 2009-06-03 20:17:27
|
On 2009-06-03 15:19-0400 Hezekiah M. Carty wrote: [...] I reworked the (only) function prototype so that it > currently looks like this: > > void > c_plarc(PLFLT x, PLFLT y, PLFLT a, PLFLT b, PLFLT angle1, PLFLT > angle2, PLFLT rotation, PLBOOL fill); > > where: > > x, y - center of the arc > a and b - semimajor and semiminor axes > angle1, angle2 - start and end angles for the arc > rotation - rotation of the arc about (x, y) > fill - should the arc be filled? Looks good to me. 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 __________________________ |
From: Hezekiah M. C. <hez...@us...> - 2009-06-03 21:03:55
|
On Wed, Jun 3, 2009 at 4:16 PM, Alan W. Irwin <ir...@be...> wrote: > On 2009-06-03 15:19-0400 Hezekiah M. Carty wrote: > > [...] I reworked the (only) function prototype so that it >> >> currently looks like this: >> >> void >> c_plarc(PLFLT x, PLFLT y, PLFLT a, PLFLT b, PLFLT angle1, PLFLT >> angle2, PLFLT rotation, PLBOOL fill); >> >> where: >> >> x, y - center of the arc >> a and b - semimajor and semiminor axes >> angle1, angle2 - start and end angles for the arc >> rotation - rotation of the arc about (x, y) >> fill - should the arc be filled? > > Looks good to me. Ok, thanks. I will check in the changes once I have the Cairo device rendering path working properly. Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science |