From: Steve S. <s.s...@im...> - 2009-04-26 10:57:47
Attachments:
qtmc_test.pdf
qtmc_test2.pdf
|
Dear All, I know you are concentrating on the next release, but wanted to post this query while it was in my mind. For our application, users typically stack many plots together on a page, often with a common X-axis, to compare different parameters at the same time. If this is done in separate plot panels, as in the first attached file, then plplots automatic labelling algorithms work pretty well and when the labelling is done using floating point notation the result is ok. However, as one adds more panels or, as in the 2nd example, controls the layout more by creating a true "stack" then the "(x10^6)" etc., appear next to the panel above. Worse, depending on how the labelling is done it is easy for these powers of 10 labels to interfere with the text-labelling of another panel. (The attached example is actually not terrible, but I could easily generate very ugly ones.) It would appear that the position and orientation of this x10^nn labelling is not under user programmer control. It would be nice to be able to control this or, perhaps better, have the option to suppress it altogether but access the resulting string (or exponent) so that we could construct a complete label, e.g., "Te.para (x10#u6#d K)". This suppression is more dangerous but offers more flexibility. Merely being able to change the position and orientation would already be a big help. This would need to be done somewhere in the core routines I suspect. Any comments on the desirability of any of this and a possible implementation? Thanks Steve -- +-------------------------------------------------------------------+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Head, Space & Atmospheric Physics Fax: +44-(0)20-7594-7900 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 711A London SW7 2AZ, U.K. Web: www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Hazen B. <hba...@ma...> - 2009-04-26 18:34:45
|
Steve Schwartz wrote: > Dear All, > > I know you are concentrating on the next release, but wanted to post > this query while it was in my mind. For our application, users typically > stack many plots together on a page, often with a common X-axis, to > compare different parameters at the same time. If this is done in > separate plot panels, as in the first attached file, then plplots > automatic labelling algorithms work pretty well and when the labelling > is done using floating point notation the result is ok. > > However, as one adds more panels or, as in the 2nd example, controls the > layout more by creating a true "stack" then the "(x10^6)" etc., appear > next to the panel above. Worse, depending on how the labelling is done > it is easy for these powers of 10 labels to interfere with the > text-labelling of another panel. (The attached example is actually not > terrible, but I could easily generate very ugly ones.) > > It would appear that the position and orientation of this x10^nn > labelling is not under user programmer control. It would be nice to be > able to control this or, perhaps better, have the option to suppress it > altogether but access the resulting string (or exponent) so that we > could construct a complete label, e.g., "Te.para (x10#u6#d K)". This > suppression is more dangerous but offers more flexibility. Merely being > able to change the position and orientation would already be a big help. > > This would need to be done somewhere in the core routines I suspect. > > Any comments on the desirability of any of this and a possible > implementation? One option is to make the graph without any labels, then add them yourself using plmtex(). This gives you complete control of the label text and position at the cost of having to layout all the labels yourself. -Hazen |
From: Steve S. <s.s...@im...> - 2009-04-26 20:43:47
|
Dear Hazen, > > It would appear that the position and orientation of this x10^nn > > labelling is not under user programmer control. It would be nice to be > > able to control this or, perhaps better, have the option to suppress it > > altogether but access the resulting string (or exponent) so that we > > could construct a complete label, e.g., "Te.para (x10#u6#d K)". This > > suppression is more dangerous but offers more flexibility. Merely being > > able to change the position and orientation would already be a big help. > > > > This would need to be done somewhere in the core routines I suspect. > > > > Any comments on the desirability of any of this and a possible > > implementation? > > One option is to make the graph without any labels, then add them > yourself using plmtex(). This gives you complete control of the label > text and position at the cost of having to layout all the labels yourself. > > -Hazen This is of course possible, but very undesirable from my perspective - only a desperate last resort. Not only does it imply manually doing the very kind of thing that plplot does so well, it also opens up the door to real errors. If we let plplot mark of the axes with ticks and then try to label them ourselves, we need to be sure we follow (= code ouselves) the same algorithm plplot uses to decide where to put the ticks, and also that we will always get the transition from fixed to floating pt correct. This sound to me like reinventing the wheel when in the simplest case all that is required is the ability to change position and orientation values (3 numbers) that are at present not accessible from the api interface. I'm not at all complaining about your suggestion. Indeed, the reason for my posting is because I had already thought about a do-it-ourselves approach and therefore wondered if someone else had also either encountered it or was more familiar with the internal plplot workings and would have the expertise to offer a more elegant and robust solution. Regards, Steve -- +-------------------------------------------------------------------+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Head, Space & Atmospheric Physics Fax: +44-(0)20-7594-7900 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 711A London SW7 2AZ, U.K. Web: www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Hazen B. <hba...@ma...> - 2009-04-26 22:17:11
|
Steve Schwartz wrote: > Dear Hazen, > >>> It would appear that the position and orientation of this x10^nn >>> labelling is not under user programmer control. It would be nice to be >>> able to control this or, perhaps better, have the option to suppress it >>> altogether but access the resulting string (or exponent) so that we >>> could construct a complete label, e.g., "Te.para (x10#u6#d K)". This >>> suppression is more dangerous but offers more flexibility. Merely being >>> able to change the position and orientation would already be a big help. >>> >>> This would need to be done somewhere in the core routines I suspect. >>> >>> Any comments on the desirability of any of this and a possible >>> implementation? >> One option is to make the graph without any labels, then add them >> yourself using plmtex(). This gives you complete control of the label >> text and position at the cost of having to layout all the labels yourself. >> >> -Hazen > > This is of course possible, but very undesirable from my perspective - > only a desperate last resort. Not only does it imply manually doing the > very kind of thing that plplot does so well, it also opens up the door > to real errors. If we let plplot mark of the axes with ticks and then > try to label them ourselves, we need to be sure we follow (= code > ouselves) the same algorithm plplot uses to decide where to put the > ticks, and also that we will always get the transition from fixed to > floating pt correct. This sound to me like reinventing the wheel when in > the simplest case all that is required is the ability to change position > and orientation values (3 numbers) that are at present not accessible > from the api interface. Ok. Do you just want to be able to move the "(x10)" label? You could rescale the data so that plplot thought that no "(x10)" label was necessary, then add that label yourself in a position and orientation that you thought was appropriate. Or did you want to be able to specify the position and orientation of all the axis labels? -Hazen |
From: Steve S. <s.s...@im...> - 2009-04-26 22:43:07
|
Hi Hazen, On Sun, 2009-04-26 at 23:16 +0100, Hazen Babcock wrote: > This sound to me like reinventing the wheel when in > > the simplest case all that is required is the ability to change > position > > and orientation values (3 numbers) that are at present not > accessible > > from the api interface. > > Ok. Do you just want to be able to move the "(x10)" label? This would do, although I'm quite familiar with requestors receiving what they originally asked for turning around almost instantly and saying that X is great, but could they also now have Y and Z? Still, if we could simply move the "(x10)" label, and possibly change its orientation by 90 degrees, that would be a good step forward. > You could > rescale the data so that plplot thought that no "(x10)" label was > necessary, then add that label yourself in a position and orientation > that you thought was appropriate. This would be possible, but again I'm fearful of (a) detecting when to do this scaling, as opposed to plplot deciding to use fixed rather than floating point and then (b) not introducing funny things, like 15 x 10^4 or such. Our software gets thrown data of all magnitudes from all sources, so we need to be robust. > Or did you want to be able to specify > the position and orientation of all the axis labels? Definitely not; the basic ticks and labelling algorithms of plplot are sound and I wouldn't want to try to reinvent them. I see Alan has added a posting; I'll respond separately to that. Cheers Steve -- +-------------------------------------------------------------------+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Head, Space & Atmospheric Physics Fax: +44-(0)20-7594-7900 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 711A London SW7 2AZ, U.K. Web: www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Alan W. I. <ir...@be...> - 2009-04-26 22:39:37
|
On 2009-04-26 21:43+0100 Steve Schwartz wrote: > I'm not at all complaining about your suggestion. Indeed, the reason for > my posting is because I had already thought about a do-it-ourselves > approach and therefore wondered if someone else had also either > encountered it or was more familiar with the internal plplot workings > and would have the expertise to offer a more elegant and robust > solution. I first want to address this issue from my perspective as one user of PLPlot in a scientific research context. _From my user perspective_ the status quo is fine. Looking at example 1 the (x10#u-2#) (where "x" stands for the times symbol) is pretty ugly wherever you put it. Thus, my opinion is adding functionality to allow the user freedom to move that ugliness around may not be adding much value. Perhaps we should instead just document that scientific notation labelling as a last resort when you have badly scaled plot axes. Since I have always thought it was ugly, I avoid that scientific notation "last resort" by properly scaling my axes. What I mean by that is I use log (z) or z/10#un#d as the variable being plotted and label it as such where "n" is chosen appropriately to give a good scaling. I far prefer the log (z) idea, but when I do scale my axes by some power of 10, the programming of that is trivial so there might not be much call for a PLplot API that does that. I acknowledge my user perspective might be wrong here, but I have never had trouble generating properly scaled plots to avoid the scientific notation so I am having trouble figuring out why it might be difficult in other contexts. Putting on my PLplot developer hat now, the trick is to balance the various user perspectives and plotting needs while trying to keep our API as non-bloated as possible. (The advantage of a non-bloated plotting API is it makes PLplot easier to learn and easier to test and maintain.) On the whole, I think we are doing pretty well with this balancing act. In this case, I have some doubts as a user that the above two API possibilities would add much value, but I could be wrong because I am only one user of PLplot. 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: Steve S. <s.s...@im...> - 2009-04-26 23:33:52
|
Hi Alan, On Sun, 2009-04-26 at 23:39 +0100, Alan W. Irwin wrote: > On 2009-04-26 21:43+0100 Steve Schwartz wrote: > > > I'm not at all complaining about your suggestion. Indeed, the reason for > > my posting is because I had already thought about a do-it-ourselves > > approach and therefore wondered if someone else had also either > > encountered it or was more familiar with the internal plplot workings > > and would have the expertise to offer a more elegant and robust > > solution. > > I first want to address this issue from my perspective as one user of PLPlot > in a scientific research context. > > _From my user perspective_ the status quo is fine. Looking at example 1 the > (x10#u-2#) (where "x" stands for the times symbol) is pretty ugly wherever > you put it. I agree that there is some ugliness no matter where the x10^nn is placed. My starting point was merely that, for our particular application, some places were uglier than others. I would add that beauty, and ugliness, is in the eye of the beholder. > Thus, my opinion is adding functionality to allow the user > freedom to move that ugliness around may not be adding much value. Perhaps > we should instead just document that scientific notation labelling as a last > resort when you have badly scaled plot axes. I think for an individual writing their own plplot code to generate a single plot frame this is probably true. E.g., if the plot is temperature in the solar corona then it would be better to divide by 10^6 and label the temperature axis "Temperature (MK)" rather than "Temperature (K) (x10^6)". Of course, for temperatures in the thousands of Kelvin lower down in the atmosphere, "Temperature (kK)" looks a bit strange, and I guess you would manually if necessary use fixed point labelling if you could. The example plots I showed are not completely typical for our software in that often there are more panels containing other parameters. These are gathered from a variety of source files and held by us as data objects on a working list, to be used for subsequent analysis and plotting. The plotting interface we have written will let a user literally drag'n'drop as many objects as they like onto a gui and then hit the plot button to generate something like what I sent out. We offer considerable control over the placement and appearance, to meet presentation and publication standards, but strive to empower our users to be able to visualise their data as qiuckly as possible in the initial stages. This speed and ease is central to the interactivie working with the data (as opposed to careful preparation for the one, final publication plot of a selected set of parameters/results). So we are at the mercy of the data supplied by external sources and the remote use of software written by us through our gui-driven application. Our software WILL allow you to scale data (and will keep track of the units) but this is initially only done so that data from different sources can be meaningfully combined. > Since I have always thought it was ugly, I avoid that scientific notation > "last resort" by properly scaling my axes. What I mean by that is I use log > (z) or z/10#un#d as the variable being plotted and label it as such where > "n" is chosen appropriately to give a good scaling. I far prefer the log (z) > idea, but when I do scale my axes by some power of 10, the programming of > that is trivial so there might not be much call for a PLplot API that does > that. I acknowledge my user perspective might be wrong here, but I have > never had trouble generating properly scaled plots to avoid the scientific > notation so I am having trouble figuring out why it might be difficult in > other contexts. I've tried above to give some insight into our context. Programming a specific example is, as you suggest, usually trivial. Programming automatic handling of the generic case is rather trickier. And it can be hard for us to second guess what our own user community would want - there's a compromise between "pretty vs ugly" on the one hand and "conventional vs scaled" units on the other. Many solar physicists, for example, hate measuring the Sun in Mm (Mega-metres) and prefer to use cm (for which a power of 10 is hard to avoid); in other circumstances, of course, they often measure things in units of the Sun's radius for the same aesthetic reasons as yours. > Putting on my PLplot developer hat now, the trick is to balance the various > user perspectives and plotting needs while trying to keep our API as > non-bloated as possible. (The advantage of a non-bloated plotting API is it > makes PLplot easier to learn and easier to test and maintain.) Yep, understood. > On the whole, I think we are doing pretty well with this balancing act. Agreed; we're quite happy to have adopted plplot for this reason; and we stuck with pgplot before that for a long time for exactly the same reason of a compact stable api. > In this case, I have some doubts as a user that the above two API > possibilities would add much value, but I could be wrong because I am only > one user of PLplot. I don't think it's a question of right or wrong - that's too black and white. After all, the plplot interface is larger than its pgplot predecessor precisely because you wanted more functionality, more power. Everyone will draw their own line somewhere; for some, the simplest use of plplot, with half a dozen lines of code to handle the box, labelling, etc., etc., and data is adequate, and hacking one of the simple plplot examples is all that is required, to their no-doubt delight. Then if they wish they can delve deeper into the API and do more things, fine tuning, etc. I think the question you raise about bloating code is probably more relevant to maintenance and testing than the user API, though I would not wish to undervalue those considerations. I'm not going to beat anyone over the head with this matter; I raised it to see if it would be worth pursuing by someone. I would point out, though, that the existing API provides the user with control over the size and position of almost everything (box, ticks, labels, titles, displacement, font, ...). Adding user control over the otherwise imposed placement of "x10^nn" would seem to be not illogical. It could be done by re-using the familiar concepts of displacement, justification, and orientation that are presently employed for axis labelling. Yours, Steve -- +-------------------------------------------------------------------+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Head, Space & Atmospheric Physics Fax: +44-(0)20-7594-7900 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 711A London SW7 2AZ, U.K. Web: www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Alan W. I. <ir...@be...> - 2009-04-27 00:53:51
|
Hi Steve: You have made a lot of good points that have pretty much convinced me we should add some functionality to our axis scaling to make it more convenient for those of our users (including especially QSAS users with all their data scaling needs) who don't want to programme axis scaling themselves. I suggest you go ahead and implement any improvement you would like to see in PLplot axis scaling. Of course, be sure and test such improvements for all anticipated QSAS axis scaling needs. I think it is too late in this release cycle to add improved axis scaling, but after next weekend's release we should be in a good position to discuss and probably incorporate your PLplot patch with or without additional changes, i.e., in the same way our collaborations on qsastime and the qt device driver have been so fruitful. 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. <hc...@at...> - 2009-04-27 02:30:30
|
On Sun, Apr 26, 2009 at 8:53 PM, Alan W. Irwin <ir...@be...> wrote: > I suggest you go ahead and implement any improvement you would like to see > in PLplot axis scaling. Of course, be sure and test such improvements for > all anticipated QSAS axis scaling needs. Would it be considered reasonable to some form of user-customizable axis labeling API in PLplot by providing callbacks similar to the pltr functions used by plcont and friends? The axis labeling code could remain mostly as-is. However, when a custom labeling function is defined, rather than rendering the text which matches the actual number at a given axis location, that number would be passed to the user-provided function. This function would return a string with the appropriate label based on the provided floating point value. If the user wants to capture extra label information in this function (scale magnitude, for example) they could do so. Something along the lines of (pseudo-code): --- function geo_label_x x: if x > 0 then "abs(x) E" else if x < 0 then "abs(x) W" else "0" function geo_label_y y: if y < 0 then "abs(y) S" else if y > 0 then "abs(y) N" else "Equator" plset_axis_label_funcs(geo_label_x, geo_label_y) --- >From here, rather than the axis labels for (-5, -5) being rendered as "-5" and "-5", then would be rendered as "5 W" and "5 S" respectively. I have something along these lines in place for the OCaml PLplot bindings, though I am still getting the code cleaned up before releasing it. Having this or something similar as a part of core PLplot would, I think, be useful. It could be used for time axes (either separate from or in conjunction with the new time handling code in PLplot), lat/lon labeling or other custom labeling purposes. If this approach is deemed acceptable I would be happy to help as much as I am able with the implementation. Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science |
From: Jonathan W. <jw...@ph...> - 2009-04-27 02:52:08
|
Hi Hez > > I suggest you go ahead and implement any improvement you would like to see > > in PLplot axis scaling. Of course, be sure and test such improvements for > > all anticipated QSAS axis scaling needs. > > Would it be considered reasonable to some form of user-customizable > axis labeling API in PLplot by providing callbacks similar to the pltr > functions used by plcont and friends? The axis labeling code could > remain mostly as-is. However, when a custom labeling function is > defined, rather than rendering the text which matches the actual > number at a given axis location, that number would be passed to the > user-provided function. This function would return a string with the > appropriate label based on the provided floating point value. If the > user wants to capture extra label information in this function (scale > magnitude, for example) they could do so. Speaking as someone who regularly prepares plots for scientific publication, having a custom labelling function for the axis labels would be great. Currently the bulk of my work isn't done using plplot but rather with a custom plotting framework I wrote around plotutils, but as part of that API I included precisely this functionality because I was always needing to label things with something apart from just the literal numeric value. So, definitely +1 from me. :-) Regards jonathan |
From: Hezekiah M. C. <hc...@at...> - 2009-04-27 17:51:11
|
On Sun, Apr 26, 2009 at 11:51 PM, Jonathan Woithe <jw...@ph...> wrote: > Hi Hez > >> > I suggest you go ahead and implement any improvement you would like to see >> > in PLplot axis scaling. Of course, be sure and test such improvements for >> > all anticipated QSAS axis scaling needs. >> >> Would it be considered reasonable to some form of user-customizable >> axis labeling API in PLplot by providing callbacks similar to the pltr >> functions used by plcont and friends? The axis labeling code could >> remain mostly as-is. However, when a custom labeling function is >> defined, rather than rendering the text which matches the actual >> number at a given axis location, that number would be passed to the >> user-provided function. This function would return a string with the >> appropriate label based on the provided floating point value. If the >> user wants to capture extra label information in this function (scale >> magnitude, for example) they could do so. > > Speaking as someone who regularly prepares plots for scientific publication, > having a custom labelling function for the axis labels would be great. > Currently the bulk of my work isn't done using plplot but rather with a > custom plotting framework I wrote around plotutils, but as part of that API > I included precisely this functionality because I was always needing to > label things with something apart from just the literal numeric value. Given that bit of encouragement and my own use for such functionality, I have started digging in to plbox.c to see what needs to happen. As it looks right now, the changes seem fairly straightforward. To avoid breaking the API, I think the simplest thing to do is to define a plslabelfunc(labelf) function, with labelf having a signature similar to: void labelf(PLINT xyz, PLFLT value, PLINT scale, PLINT precision, char* string, PLINT len, PLINT ll, PLINT lf); Arguments: - xyz: Is this a label for the X, Y or Z axis? - value: The axis value to generate a label from - scale, precision, ll, lf: See plform in plbox.c. These could be used or ignored by labelf - string: This holds the text of the label to render (plmtex formatting) - len: Maximum length of string plslabelfunc(labelf) would then associate labelf with the current plot stream. Any calls to plbox/plaxes which request a custom x or y (or z?) axis label would use labelf rather than the defaults in plbox to get the string representation of the numeric label. If no custom label function is defined then the code could either use plabort or just silently fall back on the default labeling system. Clearing custom label functions would require calling plslabelfunc(NULL). The changes to existing functions plbox.c would be fairly noninvasive, just the addition of a few more variables and if-branches. To sum up: 1) This would add one new function to the public PLplot API: plslabelfunc() 2) New constants could be added as well for the xyz argument described above 3) This would add 2 (3) new letters to the format string taken by plbox (plbox3). I propose "x" "y" and "z" for custom X, Y and Z axes, respectively. 4) This should not change any existing code - everything which does not use plslabelfunc() would continue to function as-is. Does this seem like a reasonable approach? Any suggestions for improvements? Is plslabelfunc an acceptable name or is there something better anyone wants to suggest? I don't mind more verbose function names (pl_set_label_function) but the existing PLplot API tends to be pretty terse. If this is ok'd by the powers that be I am willing to work on this during the 5.9.4 development period. Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science |
From: Jonathan W. <jw...@ph...> - 2009-05-06 03:28:25
|
Hi Hez > > Speaking as someone who regularly prepares plots for scientific publication, > > having a custom labelling function for the axis labels would be great. > > Currently the bulk of my work isn't done using plplot but rather with a > > custom plotting framework I wrote around plotutils, but as part of that API > > I included precisely this functionality because I was always needing to > > label things with something apart from just the literal numeric value. > > Given that bit of encouragement and my own use for such functionality, > I have started digging in to plbox.c to see what needs to happen. > : > To sum up: > 1) This would add one new function to the public PLplot API: plslabelfunc() > 2) New constants could be added as well for the xyz argument described above > 3) This would add 2 (3) new letters to the format string taken by > plbox (plbox3). I propose "x" "y" and "z" for custom X, Y and Z axes, > respectively. > 4) This should not change any existing code - everything which does > not use plslabelfunc() would continue to function as-is. > > Does this seem like a reasonable approach? Any suggestions for > improvements? For what it's worth this all looks good to me - if I had the time it's pretty much what I would do. It's a clean solution which doesn't break existing code. My only comment is that when a custom label is requested but no function has been supplied, I think falling back to the default labelling system (probably with a warning) is probably the sensible thing to do. > Is plslabelfunc an acceptable name or is there something better anyone > wants to suggest? It makes sense to me. Regards jonathan |
From: Schwartz, S. J <s.s...@im...> - 2009-04-27 23:03:26
|
Hez, This would seem to address everything except what I started this thread to query, namely more control over the placement of the separate exponent label when scientific notation is used for labelling. Looking a bit into the code, the placement of this string is hard-wired into the label_box{} routine in plbox.c, e.g.: sprintf(string, "(x10#u%d#d)", (int) yscale); offset = 0.02; height = 2.0; if (lny) { pos = 0.0 - offset; plmtex("t", height, pos, 1.0, string); } What I was hoping to do was to allow control these inputs to plmtext, e.g., to allow us to: Place the string at some other height from the acis Place the string at some other pos along the axis [I guess control the justification] Control, independent of the orientation of the numeric labels the orientation (e.g., "t" or "tv") of string One way to do this I guess would be to hold all these parameters in PLStream, from which label_box could get them, together with a flag indicating if the default values should be used instead. This would then require a new api routine to set these values, e.g., plsexppos(axis, orient, height, pos, just, usedefault) where axis is one of x,y, or z (PLStream would need separate entries for all three as the user can't reset them inbetween drawing the different axes from a single call to plbox) and the rest of the entries are self-explanatory and match those of plmtex. [I haven't looked at the 3d routines to see what needs to be done for the z-axis.] I could imagine an option to suppress the exponent altogether and simply return the appropriate string, so that the user could pass it directly to plmtex him/herself or, better I think, embed it in the label string - i.e., construct "Temperture (x10#u6#d K)". However, this is extremely dangerous as it relies on the user to do this, otherwise his/her plot is incorrectly labelled. I guess it would be straightforward for a user to specify the same position for both the axis label and exponent, but with one left-justified and the other right-justified and, with only a small tweak, create the same effect in a way that was less dangerous for the innocent user. Since you'll be digging into this bit of code anyway, and since you know your way 'round the plplot code and practices much better than I, perhaps you could have a go at this at the same time as you're implementing your generalised labelling routines? Cheers Steve ________________________________________ From: plp...@li... [plp...@li...] On Behalf Of Hezekiah M. Carty [hc...@at...] Sent: 27 April 2009 18:50 To: Jonathan Woithe Cc: PLplot development list; Hazen Babcock Subject: Re: [Plplot-devel] control position of floating point label On Sun, Apr 26, 2009 at 11:51 PM, Jonathan Woithe <jw...@ph...> wrote: > Hi Hez > >> > I suggest you go ahead and implement any improvement you would like to see >> > in PLplot axis scaling. Of course, be sure and test such improvements for >> > all anticipated QSAS axis scaling needs. >> >> Would it be considered reasonable to some form of user-customizable >> axis labeling API in PLplot by providing callbacks similar to the pltr >> functions used by plcont and friends? The axis labeling code could >> remain mostly as-is. However, when a custom labeling function is >> defined, rather than rendering the text which matches the actual >> number at a given axis location, that number would be passed to the >> user-provided function. This function would return a string with the >> appropriate label based on the provided floating point value. If the >> user wants to capture extra label information in this function (scale >> magnitude, for example) they could do so. > > Speaking as someone who regularly prepares plots for scientific publication, > having a custom labelling function for the axis labels would be great. > Currently the bulk of my work isn't done using plplot but rather with a > custom plotting framework I wrote around plotutils, but as part of that API > I included precisely this functionality because I was always needing to > label things with something apart from just the literal numeric value. Given that bit of encouragement and my own use for such functionality, I have started digging in to plbox.c to see what needs to happen. As it looks right now, the changes seem fairly straightforward. To avoid breaking the API, I think the simplest thing to do is to define a plslabelfunc(labelf) function, with labelf having a signature similar to: void labelf(PLINT xyz, PLFLT value, PLINT scale, PLINT precision, char* string, PLINT len, PLINT ll, PLINT lf); Arguments: - xyz: Is this a label for the X, Y or Z axis? - value: The axis value to generate a label from - scale, precision, ll, lf: See plform in plbox.c. These could be used or ignored by labelf - string: This holds the text of the label to render (plmtex formatting) - len: Maximum length of string plslabelfunc(labelf) would then associate labelf with the current plot stream. Any calls to plbox/plaxes which request a custom x or y (or z?) axis label would use labelf rather than the defaults in plbox to get the string representation of the numeric label. If no custom label function is defined then the code could either use plabort or just silently fall back on the default labeling system. Clearing custom label functions would require calling plslabelfunc(NULL). The changes to existing functions plbox.c would be fairly noninvasive, just the addition of a few more variables and if-branches. To sum up: 1) This would add one new function to the public PLplot API: plslabelfunc() 2) New constants could be added as well for the xyz argument described above 3) This would add 2 (3) new letters to the format string taken by plbox (plbox3). I propose "x" "y" and "z" for custom X, Y and Z axes, respectively. 4) This should not change any existing code - everything which does not use plslabelfunc() would continue to function as-is. Does this seem like a reasonable approach? Any suggestions for improvements? Is plslabelfunc an acceptable name or is there something better anyone wants to suggest? I don't mind more verbose function names (pl_set_label_function) but the existing PLplot API tends to be pretty terse. If this is ok'd by the powers that be I am willing to work on this during the 5.9.4 development period. Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Plplot-devel mailing list Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Maurice L. <mj...@br...> - 2009-04-27 23:31:43
|
This discussion bears on an unfortunate liability of traditional API's -- their quick obsolescence when new features / capabilities are brought online. Back when I was into generating a lot more types of plots than I do now, I even built my own front-end to plplot to control many aspects of the plotting. A lot of it was tied to my own personal needs so I never felt comfortable folding it into the library proper. Anyhow, one thing I found very useful was to control via state variables instead of functional ones. That is, I had calls xxsetf( "foo", <value of float parameter foo> ) that allowed an arbitrary amount of control with no API change necessary. I think the number of settable parameters I had may have been in the 100's range, but it's a bit fuzzy now. Didn't have to worry about obsoleting that API very often after that. So something to consider. -- Maurice LeBrun |