From: Alan W. I. <ir...@be...> - 2010-09-09 19:00:21
|
I am transferring this discussion from plplot-general to plplot-devel with a different subject. On 2010-09-09 10:36-0400 Hezekiah M. Carty wrote: > The OCaml bindings include a character_height function which (should?) > return the character height in world coordinates: > > http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/bindings/ocaml/plplot.ml?revision=11020&view=markup > > The function begins on line 611 and should be fairly self-explanatory. > There is likely a simpler way to do this using internal PLplot > functions, but this method allows you to stick to the public, > documented API. > I am not that good at reading OCaml code, but it looks like the method combines results from plgch, plgvpd, plgspa, and plgvpw. From the documentation of those, you should be able to use the combination of plgspa and plgvpd to obtain the viewport limits in mm. Then combine those results with plgvpw results (which obtains the viewport limits in world coordinates) to determine the ratio of world coordinates to mm in the y direction. Then use that factor to transform plgchr height results in mm to world coordinates. So I think this idea should work fine, but it would not be necessary if we had a central libplplot pllegend capability which simply accessed the required internal variables directly. I have brought up the central legend-drawing topic because I noticed plplot.ml contained the draw_legend function which uses the result from the character_height function beginning on line 611 to draw a legend. The octave interface also has a legend-drawing capability, and it appears that the original poster on plplot-general also has a need for that capability in Perl/PDL. If not obvious already, it appears from all these lines of evidence that PLplot needs a legend-drawing capability in its core library. Hez, from your OCaml experience with legends would you be willing to implement a legend-drawing capability in libplplot and also modify one of our C examples to use that new API? (I assume from here on that that new function would be called pllegend.) If you were willing to do that implementation, I (and presumably others from past history) would be willing to help out afterward with the usual API addition tasks of pllegend documentation and propagating the pllegend API and its use in a standard example to all our languages. I believe the ultimate result of a well-documented and uniform pllegend capability for all our languages would be a welcome improvement to 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: Alan W. I. <ir...@be...> - 2010-09-11 20:57:04
|
On 2010-09-11 00:47-0400 Hezekiah M. Carty wrote: > On Fri, Sep 10, 2010 at 9:09 PM, Alan W. Irwin > <ir...@be...> wrote: >> On 2010-09-10 18:46-0400 Hezekiah M. Carty wrote: >> >>> The initial version of pllegend is now in PLplot trunk, revision >>> 11165. >> >> Thanks very much for this effort. However, it appears you forgot to >> svn add and commit your new pllegend.c. Once that rather urgent >> (since it makes builds impossible) issue is straightened out, I look >> forward to seeing what the new legend is going to look like for >> example 4. >> > > Ouch - that's quite embarrassing! Thank you for pointing out the > oversight, and my apologies for missing that. No problem. Been there, done that. Thanks for addressing this so quickly. > > Revision 11166 adds pllegend.c, and will hopefully build successfully. Yes, that built without problems for me, but I noticed a legend limitation in example 4 (only two symbols were allowed per legend line) which I have subsequently fixed (which required an API change). I also used line_length properly in pllegend and did some character size _and_ symbol size offset adjustments. (revision 11168). I also made a temporary change (revision 11169) to example 4 to display offsets at a large scale for diagnostic purposes. The result I get for best alignment includes a factor of 0.5 fudge factor for the symbol width used to adjust the position of the ends of the line of symbols. I don't understand that factor at all. I hope you like these changes. If you compare -dev xwin with either -dev xcairo or -dev wxwidgets for the current example 4 it is clear there is still a small but consistent vertical offset error for the latter two devices. I will look further into this side issue. Andrew, would you please comment on the general API question using your knowledge of our octave bindings and examples? There is a legend capability in our octave bindings which is used in many of the special "p" octave examples, and I want to make sure the C version has at least the same designed capabilities. It needs an octave expert to figure out what the octave legend design is because the implementation of it currently sucks with a lot of difficulties concerning sizes and offsets. For example, the psc results you get with "make test_octave_psc" show legends for most examples but with much of the legend cut off. (As an aside, it would be good to sort out those octave legend issues if at all possible.) I then tried "make test_octave_xwin" with temporarily modified bindings/octave/PLplot/figure.m to turn off the -np default so I could look at individual interactive plots without them roaring by so fast I could not see anything. Again, you get mostly cut off legends, but in a few cases you can see enough so it is clear there is an attempt to present cmap1 results in the legends to help interpret shaded plots. Even without Andrew's additional help here with clarifying what Joao Cardosa was attempting to do with legend capability in the octave bindings, it is clear from the slowed interactive results that they include at least cmap1 (continuous colour) results. I believe we need that capability in pllegend. I also believe we need a cmap0 discrete colour capability. The cmap1 capability should have numerical labels (created using our already existing internal axis labelling routines) in the world coordinate cooresponding to the cmap1 floating index range from 0. to 1. The cmap0 capability would have discrete text (similar to what we have now for each of the lines in pllegend) to interpret each of the discrete colours. Hez, do you agree with these general ideas? If so, let's think up an ideal pllegend API that will allow both cmap0 and cmap1 colour capabilities as well as the current line and symbol capabilities, and if we run out of time before this release, we can hopefully implement the colour details later without changing that ideal API. To get that discussion rolling, I think we need a switch variable in the argument list to decide which of line, symbol, cmap0, or cmap1 legend is being created. For cmap0 the number of discrete colours that will be shown in the legend will be the same as the current number of legend entries, n, and the width of the colour box. (The height of each one of those boxes can be calculated internally depending on the number of discrete colours.) For cmap1, we need the width of the colour box used to represent all the continuous colours. That can be the same as the cmap0 width. We also need wmin and wmax values that are the world coordinates corresponding to cmap1 index values of 0. and 1. Anything else? Of course, Hez, if you want to go ahead and implement colour capability for pllegend following roughly what I said above, that would be great. Real code is always better than speculation about the best API. 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: Alan W. I. <ir...@be...> - 2010-09-12 01:17:56
|
On 2010-09-11 13:56-0700 Alan W. Irwin wrote: > If you compare -dev xwin with either -dev xcairo or -dev wxwidgets for > the current example 4 it is clear there is still a small but > consistent vertical offset error for the latter two devices. > I will look further into this side issue. After running make -j4 _plplotcmodule make python_examples xwin cairo qt try the new version (revision 11171) of test_circle.py, e.g., examples/python/test_circle.py -dev xwin which demonstrates in a simple way that the asterisk is aligned perfectly for Hershey fonts with -dev xwin wherever the appropriate encoding method is used ("*" or "#(728)" with plptex, plsym with index 728 or plpoin with index 3). However, for xcairo and qtwidget the asterisk with plptex is badly misaligned if encoded as "*" or as the PLplot unicode encoding "#[0x002a]". For xcairo and qtwidget, plptex with "#(728)" is slightly misaligned. Why should there be such a big difference in position alignment between those two encodings which should boil down to the exact same calls internally for these unicode drivers? A further puzzle is that for xcairo (with pls->alt_unicode = 1), plsym and plpoin give slightly different alignments than plptex with "#(728)". Again, the code paths should boil down to the same thing internally for this unicode driver if the pls->alt_unicode = 1 code path is working correctly. Just to make your head spin a bit more, qtwidget (which uses pls->alt_unicode = 0) generates consistent (but slightly misaligned) results for plptex with "#(728)", plsym, and plpoin. It is pretty clear there is more than one character/symbol unicode misalignment bug being revealed by these test_circle.py results. For example, pls->alt_unicode=0 or 1 is probably playing a small role for the small misalignment cases, but that different code path makes no noticeable difference for the bad misalignment cases referenced above. I have put this issue on our bugtracker (bug 3064564). There are some other PLplot issues that I want to deal with first so if fixing these bug(s) is strictly up to me, I will probably put off dealing with this to much later. However, if any one else is interested in tracking down and fixing these issues before me, we at least have a good test case with test_circle.py showing the various kinds of unicode character misalignment problems in great detail. 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: Arjen M. <arj...@de...> - 2010-09-14 07:02:27
|
Hi Hez, On 2010-09-11 22:56, Alan W. Irwin wrote: >>> On 2010-09-10 18:46-0400 Hezekiah M. Carty wrote: >>> >>>> The initial version of pllegend is now in PLplot trunk, revision >>>> 11165. > To get that discussion rolling, I think we need a switch variable in > the argument list to decide which of line, symbol, cmap0, or cmap1 > legend is being created. For cmap0 the number of discrete colours > that will be shown in the legend will be the same as the current > number of legend entries, n, and the width of the colour box. (The > height of each one of those boxes can be calculated internally > depending on the number of discrete colours.) For cmap1, we need the > width of the colour box used to represent all the continuous colours. > That can be the same as the cmap0 width. We also need wmin and wmax > values that are the world coordinates corresponding to cmap1 index > values of 0. and 1. > > Anything else? > I took the opportunity to change the function get_character_and_symbol_height() to a static function - just to be on the safe side. Some remarks: I have seen in the past that the C++ style of comments (//) is not accepted by all C compilers (notably MSVC/C++ 9.0 or so, in C mode - there may be a flag to allow that). I will go and change these comments to regular C style, if you all agree. The line style and thickness are other aspects of an entry in a legend that we need to take care of. Of course, this makes the argument list a trifle lengthy, but there probably is no real alternative. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2010-09-16 00:05:20
|
On 2010-09-14 09:02+0200 Arjen Markus wrote: > The line style and thickness are other aspects of an entry in a legend > that we need to take care of. DONE as of revision 11187. Background (semi-transparent) colour, option for text on the left, cmap0, and cmap1 are all in my further plans. 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: Alan W. I. <ir...@be...> - 2010-09-14 14:37:42
|
Hi Arjen: I have changed the subject line for obvious reasons. On 2010-09-14 09:02+0200 Arjen Markus wrote: > I have seen in the past that the C++ style of > comments (//) is not accepted by all C compilers (notably MSVC/C++ 9.0 > or so, in C mode - there may be a flag to allow that). I will go and > change these comments to regular C style, if you all agree. I think we should positively encourage // style comments in our C code. The nice thing about // is that it is well-recognized by everybody reading code and clearly visible (unlike the traditional C style comments for the multiline case unless you fiddle around with leading asterisks or other workarounds). In the past there were two issues brought up for the // style. I. Will it cause compiler issues? It turns out that style is accepted as part of c99, and when c99 has come up before on this list, I don't think anybody could find an instance of a C compiler that did not accept c99. I am not familar with MSVC/C++ 9.0. Does it predate c99 or otherwise not honour that standard? Anyhow, I would appreciate you clearing up this doubt by checking whether // causes problems for that compiler. II. Might screw up doxygen style comments. However, it turns out that doxygen is well aware of the // style, and it is no problem. When I discussed these arguments before on list nobody objected at the time to the // style so I have been using that style ever since (with no reported compiler issues), and I think it is fine that Hez is using it as well (so long as there are no popular compilers that this causes trouble for). At some point (assuming there are no compiler issues) I would like to change all our traditional C style commentary over to the // style. I have made a request to the uncrustify list on this matter. If they don't implement a style parameter to that effect, then the job could be done with a python script. 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: Arjen M. <arj...@de...> - 2010-09-14 14:53:26
|
Hi Alan, well, this is clearly something I will have to look into. Regards, Arjen On 2010-09-14 16:37, Alan W. Irwin wrote: > Hi Arjen: > > I have changed the subject line for obvious reasons. > > On 2010-09-14 09:02+0200 Arjen Markus wrote: > >> I have seen in the past that the C++ style of >> comments (//) is not accepted by all C compilers (notably MSVC/C++ 9.0 >> or so, in C mode - there may be a flag to allow that). I will go and >> change these comments to regular C style, if you all agree. > > I think we should positively encourage // style comments in our C > code. The nice thing about // is that it is well-recognized by > everybody reading code and clearly visible (unlike the traditional C > style comments for the multiline case unless you fiddle around with > leading asterisks or other workarounds). > > In the past there were two issues brought up for the // style. > > I. Will it cause compiler issues? It turns out that style is > accepted as part of c99, and when c99 has come up before on this list, > I don't think anybody could find an instance of a C compiler that did > not accept c99. I am not familar with MSVC/C++ 9.0. Does it predate > c99 or otherwise not honour that standard? Anyhow, I would appreciate > you clearing up this doubt by checking whether // causes problems for > that compiler. > > II. Might screw up doxygen style comments. However, it turns out that > doxygen is well aware of the // style, and it is no problem. > > When I discussed these arguments before on list nobody > objected at the time to the // style so I have been using that style > ever since (with no reported compiler issues), and I think it is fine > that Hez is using it as well (so long as there are no popular > compilers that this causes trouble for). > > At some point (assuming there are no compiler issues) I would > like to change all our traditional C style commentary over to the // > style. I have made a request to the uncrustify list on this matter. > If they don't implement a style parameter to that effect, then the job > could be done with a python script. > > 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 > __________________________ > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2010-09-14 16:35:26
|
Hi Hez: I changed pllegend.c svn properties to native line endings (which should cut down on the line-ending noise we see in further svn diffs). I implied before that I was hoping you would implement my cmap0 and cmap1 pllegend ideas, but I have now decided to work on those today myself. Alan Hi Arjen: On 2010-09-14 09:02+0200 Arjen Markus wrote: > I took the opportunity to change the function > get_character_and_symbol_height() to a static function - just to be > on the safe side. Thanks. > The line style and thickness are other aspects of an entry in a legend > that we need to take care of. Of course, this makes the argument list > a trifle lengthy, but there probably is no real alternative. Good idea. 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: Alan W. I. <ir...@be...> - 2010-09-15 03:14:42
|
On 2010-09-14 09:35-0700 Alan W. Irwin wrote: > [...]I have now decided to work on those (cmap0 and cmap1 legends) today > myself. Well, I worked on other pllegend issues, and as a result there is now (revision 11183) no longer any necessity to call pllegend twice in example 4. I hope to start implementing cmap0 and cmap1 legend functionality tomorrow (Wednesday). 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: Arjen M. <arj...@de...> - 2010-09-15 06:45:23
|
Hi Alan, I checked this - the MSVC/C++ compiler I am using (reportedly version 15.x under Visual Studio 2008) does accept // comments. I am sure I had problems with that before, but they are gone. So, my questioning the use of // is not important anymore. Regards, Arjen On 2010-09-14 16:37, Alan W. Irwin wrote: > Hi Arjen: > > I have changed the subject line for obvious reasons. > > On 2010-09-14 09:02+0200 Arjen Markus wrote: > >> I have seen in the past that the C++ style of >> comments (//) is not accepted by all C compilers (notably MSVC/C++ 9.0 >> or so, in C mode - there may be a flag to allow that). I will go and >> change these comments to regular C style, if you all agree. > > I think we should positively encourage // style comments in our C > code. The nice thing about // is that it is well-recognized by > everybody reading code and clearly visible (unlike the traditional C > style comments for the multiline case unless you fiddle around with > leading asterisks or other workarounds). > > In the past there were two issues brought up for the // style. > > I. Will it cause compiler issues? It turns out that style is > accepted as part of c99, and when c99 has come up before on this list, > I don't think anybody could find an instance of a C compiler that did > not accept c99. I am not familar with MSVC/C++ 9.0. Does it predate > c99 or otherwise not honour that standard? Anyhow, I would appreciate > you clearing up this doubt by checking whether // causes problems for > that compiler. > > II. Might screw up doxygen style comments. However, it turns out that > doxygen is well aware of the // style, and it is no problem. > > When I discussed these arguments before on list nobody > objected at the time to the // style so I have been using that style > ever since (with no reported compiler issues), and I think it is fine > that Hez is using it as well (so long as there are no popular > compilers that this causes trouble for). > > At some point (assuming there are no compiler issues) I would > like to change all our traditional C style commentary over to the // > style. I have made a request to the uncrustify list on this matter. > If they don't implement a style parameter to that effect, then the job > could be done with a python script. > > 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 > __________________________ > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2010-09-15 14:31:41
|
On 2010-09-15 08:44+0200 Arjen Markus wrote: > Hi Alan, > > I checked this - the MSVC/C++ compiler I am using (reportedly version 15.x > under Visual Studio 2008) does accept // comments. I am sure I > had problems with that before, but they are gone. So, my questioning the > use of // is not important anymore. Thanks, Arjen, for doing this detective work. >From this evidence it looks like we are free to use // style comments for all our C code. My eventual goal is all C comments will use this style (either through a new uncrustify option or a script to enforce this). 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...> - 2010-09-18 20:10:49
Attachments:
image_colorbar_example.png
|
On Sat, Sep 11, 2010 at 4:56 PM, Alan W. Irwin <ir...@be...> wrote: > On 2010-09-11 00:47-0400 Hezekiah M. Carty wrote: > >> On Fri, Sep 10, 2010 at 9:09 PM, Alan W. Irwin >> <ir...@be...> wrote: >>> >>> On 2010-09-10 18:46-0400 Hezekiah M. Carty wrote: >>> >>>> The initial version of pllegend is now in PLplot trunk, revision >>>> 11165. >>> >>> Thanks very much for this effort. However, it appears you forgot to >>> svn add and commit your new pllegend.c. Once that rather urgent >>> (since it makes builds impossible) issue is straightened out, I look >>> forward to seeing what the new legend is going to look like for >>> example 4. >>> >> >> Ouch - that's quite embarrassing! Thank you for pointing out the >> oversight, and my apologies for missing that. > > No problem. Been there, done that. Thanks for addressing this so > quickly. > >> >> Revision 11166 adds pllegend.c, and will hopefully build successfully. > > Yes, that built without problems for me, but I noticed a legend > limitation in example 4 (only two symbols were allowed per legend > line) which I have subsequently fixed (which required an API change). I also > used line_length properly in pllegend and did some character > size _and_ symbol size offset adjustments. (revision 11168). I also > made a temporary change (revision 11169) to example 4 to display > offsets at a large scale for diagnostic purposes. The result I get > for best alignment includes a factor of 0.5 fudge factor for the symbol > width used to adjust the position of the ends of the line of symbols. > I don't understand that factor at all. > > I hope you like these changes. > Those all look like good changes to me as well. I haven't had a chance to look in detail at the factor of 0.5, but I didn't see anything obvious in my brief scan through the code. My main question about the API changes you made is if it would be better to provide the opt parameter as an array, with one element per legend entry. This should make it easier to use pllegend with several mixed entry types. > > It needs an octave expert to figure out what the octave legend design > is because the implementation of it currently sucks with a lot of > difficulties concerning sizes and offsets. For example, the psc > results you get with "make test_octave_psc" show legends for most > examples but with much of the legend cut off. (As an aside, it would > be good to sort out those octave legend issues if at all possible.) I > then tried "make test_octave_xwin" with temporarily modified > bindings/octave/PLplot/figure.m to turn off the -np default so I could > look at individual interactive plots without them roaring by so fast I > could not see anything. Again, you get mostly cut off legends, but in > a few cases you can see enough so it is clear there is an attempt to > present cmap1 results in the legends to help interpret shaded plots. > > Even without Andrew's additional help here with clarifying what Joao > Cardosa was attempting to do with legend capability in the octave > bindings, it is clear from the slowed interactive results that they > include at least cmap1 (continuous colour) results. I believe we need > that capability in pllegend. I also believe we need a cmap0 discrete > colour capability. The cmap1 capability should have numerical labels > (created using our already existing internal axis labelling routines) > in the world coordinate cooresponding to the cmap1 floating index > range from 0. to 1. The cmap0 capability would have discrete text > (similar to what we have now for each of the lines in pllegend) to > interpret each of the discrete colours. > > Hez, do you agree with these general ideas? If so, let's think up an > ideal pllegend API that will allow both cmap0 and cmap1 colour > capabilities as well as the current line and symbol capabilities, and > if we run out of time before this release, we can hopefully implement > the colour details later without changing that ideal API. > I think that we are getting in to an area where we should have two functions here - the current pllegend for line and symbol plots, and a separate function (plcolorbar?) for discrete and continuous color value references. pllegend is to plline and plpoin what plcolorbar would be to the plimage functions and the plshade functions. The OCaml bindings already have a function for drawing discrete and continuous color bars. These are separate from one another and separate from the legend support because they require significantly different arguments. The color bar functions in the OCaml bindings also position the color bar relative to the device edge rather than inside of the plot window. See the attached example for an example of the image colorbar in use. The continuous color bar would always use cmap1. However, it is probably useful to support both cmap0 and cmap1 in the discrete colorbar case since the plshade functions can plot with either color scale. For the higher level OCaml interface, you provide the following to draw a discrete or continuous color bar: image_colorbar ?custom_axis ?label ?log ?pos ?width data shade_colorbar ?custom_axis ?label ?log ?pos ?width data where the "?" indicates an optional parameter. - custom_axis: Should the scale be labeled with a custom labeling function? - label: A text label to draw to one side of the color bar - log: Is the data log-scaled (this affects the axis labeling, not the drawn data) - pos: Position on the page, specified as a normalized offset from an edge of the plot page. This can be relative to the top, bottom, right or left. - width: How wide should the color bar be on the plot page - data: Either a pair of min, max values for a cmap1 continuous color bar, or an array of n discrete values to use when shading a discrete color bar The OCaml color bar functions work by creating a new plot window and drawing with one of the plimage functions or plshade functions within that window. This makes it easy to place the window outside or inside the main plot window. If this approach is taken in the C implementation then it may also be worth including a plpush_config and a plpop_config function which save and restore, respectively, the current state of the plot stream (drawing color, window parameters, etc.). There are a lot of plot parameters to save and restore in this process. Any thoughts? Hez |
From: Alan W. I. <ir...@be...> - 2010-09-25 22:32:28
|
On 2010-09-18 16:10-0400 Hezekiah M. Carty wrote: > Those all look like good changes [to pllegend] to me as well. I haven't had a > chance to look in detail at the factor of 0.5, but I didn't see > anything obvious in my brief scan through the code. > > My main question about the API changes you made is if it would be > better to provide the opt parameter as an array, with one element per > legend entry. This should make it easier to use pllegend with several > mixed entry types. Good idea. I have implemented opt_array to specify which of line, symbol, and/or cmap0 legend type is being used for each legend index. opt will continue to be used for overall options (including PL_LEGEND_CMAP1 which will not change from one legend index to the next). >> Hez, do you agree with these general [cmap0/cmap1] ideas? If so, let's think up an >> ideal pllegend API that will allow both cmap0 and cmap1 colour >> capabilities as well as the current line and symbol capabilities, and >> if we run out of time before this release, we can hopefully implement >> the colour details later without changing that ideal API. >> > > I think that we are getting in to an area where we should have two > functions here - the current pllegend for line and symbol plots, and a > separate function (plcolorbar?) for discrete and continuous color > value references. pllegend is to plline and plpoin what plcolorbar > would be to the plimage functions and the plshade functions. There are some similarities between the line/symbol legends and the colour/bar ones. For example, semi-transparent background, whether text is on the left, length of text, colour and size of text, etc. See the detailed current API (which excludes cmap1 for the moment) explained in the commit message for revision 11210 where I did a complete rewrite of pllegend which added a lot of capability. The current status (revision 11212) is I feel that API is complete for line, symbol, and cmap0 (although some aspects of it (e.g., cmap0) still need to be implemented). I hope to finish all the remaining implementation of the current pllegend API later today, and then move on to designing and implementing the cmap1 part of that API (after reviewing your ideas on that) by early next week assuming it fits in nicely with pllegend. Once the pllegend API includes cmap1 and is therefore complete, I hope you will review it, but meanwhile your preliminary review of the current part of the API that excludes cmap1 functionality would be quite useful as well. For example, I have made the assumption that all text configurables will not change from one legend index to the next. I think that is obviously true of size, spacing, justification, etc., but how about text colour? If you have time, I hope you also play with the pllegend call in x04c.c to evaluate just how powerful the pllegend capability is becoming. > The OCaml color bar functions work by creating a new plot window and > drawing with one of the plimage functions or plshade functions within > that window. This makes it easy to place the window outside or inside > the main plot window. If this approach is taken in the C > implementation then it may also be worth including a plpush_config and > a plpop_config function which save and restore, respectively, the > current state of the plot stream (drawing color, window parameters, > etc.). There are a lot of plot parameters to save and restore in this > process. The current status is the legend must be inside the viewport, but I believe it should be straightforward to choose a temporary new viewport for the legend corresponding to the legend dimensions. (I already know those dimensions from my recent implementation of a background for the legend.) This should take care of all clipping issues, e.g., allow putting the legend anywhere (inside or outside the initial viewport) in the subpage. A temporary viewport does add to the list of quantities that need to be saved/restored, but currently that list is pretty small so I would probably just add to that list rather than saving/restoring all stream data. I will try and squeeze the above internal implementation changes in after the cmap1 work, but if I find I am working too close to the release date next weekend, I plan to put these internal changes off until after the release since they shouldn't affect the pllegend API, and making changes too close to the release always seems to cause trouble. Post release we should also make a concerted effort to fix up plstrl so that it reports correct string lengths for more than just device drivers that use Hershey fonts. Currently, the net effect of these plstrl string-length errors for non-Hershey devices such as the cairo and qt devices is that the background is misaligned (right-hand edge too far to the right). The alignment of the background does look good for the Hershey fonts used for -dev xwin. 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: Alan W. I. <ir...@be...> - 2010-09-26 01:04:01
|
Hi again, Hez: On 2010-09-25 15:32-0700 Alan W. Irwin wrote: > Once the pllegend API includes cmap1 and is therefore complete, I hope > you will review it, but meanwhile your preliminary review of the > current part of the API that excludes cmap1 functionality would be > quite useful as well. For example, I have made the assumption that all > text configurables will not change from one legend index to the next. > I think that is obviously true of size, spacing, justification, etc., > but how about text colour? If you have time, I hope you also play > with the pllegend call in x04c.c to evaluate just how powerful the > pllegend capability is becoming. I realized I could use text colours that could be changed with legend index even for example 4 so I changed (revision 11216) the API and example accordingly. I suspect a fresh pair of eyes looking at the current pllegend API might turn up other things that could be profitably changed so please take a look. 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: Alan W. I. <ir...@be...> - 2010-09-26 04:50:52
|
On 2010-09-25 15:32-0700 Alan W. Irwin wrote: > I hope to finish all the remaining implementation of the current > pllegend API later today DONE as of revision 11219. I have now tested everything related to line-, symbol-, and cmap0-style legends as well as PL_LEGEND_TEXT_LEFT, and everything looks good (except for the plstrl issues mentioned before for non-Hershey device drivers). > and then move on to designing and > implementing the cmap1 part of that API (after reviewing your ideas on > that) by early next week assuming it fits in nicely with pllegend. I plan to start on the cmap1 part tomorrow (Sunday). I feel confident the end result will be a powerful legend capability for PLplot that should satisfy virtually everybody's legend needs. 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...> - 2010-09-30 15:02:52
|
On Thu, Sep 30, 2010 at 1:56 AM, Alan W. Irwin <ir...@be...> wrote: >> I gave the change a shot. I don't want to commit without getting some >> feedback, so I have attached a test patch for pllegend.c and x04c.c >> for your consideration. I think the result is positive overall. >> >> Thoughts? > > I looked at the patch to make sure I had understood you before. (I > had.) Note in the example I just posted, the exact same number of > quantities are specified as in your patch to x04c.c, but with a > uniform index of 0 for the data for the first legend entry and a > uniform index of 1 for the data for the second legend entry. Sorry, > but I just feel that uniform indices are much easier for humans to > understand so I would like to stick with the status quo. > Thanks for the quick respons! Those are all valid points, and given those I'm happy to stick with the current implementation. Hez |
From: Andrew R. <and...@us...> - 2010-09-30 20:10:34
|
On Thu, Sep 30, 2010 at 11:02:24AM -0400, Hezekiah M. Carty wrote: > On Thu, Sep 30, 2010 at 1:56 AM, Alan W. Irwin > <ir...@be...> wrote: > >> I gave the change a shot. ??I don't want to commit without getting some > >> feedback, so I have attached a test patch for pllegend.c and x04c.c > >> for your consideration. ??I think the result is positive overall. > >> > >> Thoughts? > > > > I looked at the patch to make sure I had understood you before. ??(I > > had.) Note in the example I just posted, the exact same number of > > quantities are specified as in your patch to x04c.c, but with a > > uniform index of 0 for the data for the first legend entry and a > > uniform index of 1 for the data for the second legend entry. ??Sorry, > > but I just feel that uniform indices are much easier for humans to > > understand so I would like to stick with the status quo. > > > > Thanks for the quick respons! Those are all valid points, and given > those I'm happy to stick with the current implementation. I think I agree with Alan on this one. Andrew |
From: Alan W. I. <ir...@be...> - 2010-10-01 21:26:28
|
To Hez and Andrew: I have just assigned the "const" qualifier to all array arguments of pllegend. I think this is the right thing to do, and it seems to work fine, but neither of you mentioned this possibility when reviewing the pllegend API, and I am inexperienced with the "const" nuances. Furthermore, I notice with other PLplot functions many (but not all) array arguments do not have the "const" qualifier. So if there are downsides please let me know before the release so I can change it back. If the decision is pro "const", should we be using this qualifier for most of the array arguments to PLplot functions? Of course, that is a large backwards-incompatible API change so we would have to pick our moment when we wanted to do that change. 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...> - 2010-09-28 12:55:51
|
On Sun, Sep 26, 2010 at 12:50 AM, Alan W. Irwin <ir...@be...> wrote: > On 2010-09-25 15:32-0700 Alan W. Irwin wrote: >> and then move on to designing and >> implementing the cmap1 part of that API (after reviewing your ideas on >> that) by early next week assuming it fits in nicely with pllegend. > > I plan to start on the cmap1 part tomorrow (Sunday). I feel confident > the end result will be a powerful legend capability for PLplot that > should satisfy virtually everybody's legend needs. > Aside from the question about the cmap[01]_colors, cmap_patterns, cmap_scales questions I brought up in the 5.9.7 release thread, my main concerns come down to types: 1. text_justification is defined as a PLINT, but from the doxygen documentation it looks like it should be a PLFT. 2. With support for cmap1 elsewhere in pllegend, would it be reasonable to add support for cmap1 line and symbol colors? Do people generally use cmap1 for line or symbol plots? If this is allowed then most of the color parameters would need to take PLFLT values/arrays. 3. In the 5.9.7 release thread you mentioned the ability to skip entries when using pllegend interactively. Could this be specified explicitly? Should there be a PL_LEGEND_NONE option defined (= 0 I think) for opt_array? This isn't strictly necessary as passing 0 would do the same thing, but it would make the intent of code using this skipping functionality a bit easier to see. PL_LEGEND_NONE wouldn't need a special case in the pllegend implementation, just a #define along with the other PL_LEGEND_* options. I like pllegend in its current state overall. I do, however, think that it is worth encouraging the PLplot developers and interested users to try out the pllegend API post-5.9.7 before we commit to keeping the API as-is. In particular, some real-world use and a plcolorbar implementation may expose other options we would like to provide in pllegend. Thank you again for all of your work on this! Hez |
From: Alan W. I. <ir...@be...> - 2010-09-28 18:03:31
|
On 2010-09-28 08:43-0400 Hezekiah M. Carty wrote: > On Sun, Sep 26, 2010 at 12:50 AM, Alan W. Irwin > <ir...@be...> wrote: >> On 2010-09-25 15:32-0700 Alan W. Irwin wrote: >>> and then move on to designing and >>> implementing the cmap1 part of that API (after reviewing your ideas on >>> that) by early next week assuming it fits in nicely with pllegend. >> >> I plan to start on the cmap1 part tomorrow (Sunday). I feel confident >> the end result will be a powerful legend capability for PLplot that >> should satisfy virtually everybody's legend needs. >> > > Aside from the question about the cmap[01]_colors, cmap_patterns, > cmap_scales questions I brought up in the 5.9.7 release thread, my > main concerns come down to types: > > 1. text_justification is defined as a PLINT, but from the doxygen > documentation it looks like it should be a PLFT. Good catch! Fixed as of revision 11230. > 2. With support for cmap1 elsewhere in pllegend, would it be > reasonable to add support for cmap1 line and symbol colors? Yes. > Do people > generally use cmap1 for line or symbol plots? I think we only have one instance of that in our examples so users may not have picked up on this possibility, but it has long been the case that plcol0 and plcol1 could be used interchangably so perhaps we should arrange that for pllegend as well. To implement this, I think we need an overall PL_LEGEND_CMAP1 opt flag and we should replace PL_LEGEND_CMAP0 and PL_LEGEND_CMAP1 in opt_array with PL_LEGEND_DISCRETE_COLOR. If the overall PL_LEGEND_CMAP1 opt flag is set, _all_ color indices are interpreted as PLFLT cmap1 values in the range from 0. to 1., but otherwise they are interpreted as PLINT cmap0 index values. One potential downside to having cmap0 and cmap1 alternatives for all colors is a proliferation of alternative PLINT cmap0 or PLFLT cmap1 arguments such as the current PLINT *cmap0_colors, PLFLT * cmap1_colors arguments. Could we just use generic pointer (void *) arguments to stand in for either kind of cmap index/value to halve the number of color arguments? I have very little experience with using void *, so if you think this idea would work, could you illustrate what to do with a commit that replaces the current PLINT *cmap0_colors, PLFLT * cmap1_colors arguments with one generic pointer argument? Then I could propagate that idea to all our other color arguments, e.g., bg_color, text_colors, line_colors, symbol_colors (which are currently restricted to just cmap0). Are there any downsides to using generic pointers for something like this? For example, will such pointers make it difficult to propagate pllegend to some of our languages? Whatever we decide to do here, I think we should be consistent. So if you don't think it is a good idea to provide both cmap0 and cmap1 alternatives for all colour arguments (through generic pointers), then I think we should probably consistently use cmap0 arguments for all colors, i.e., drop the PLFLT * cmap1_colors argument and replace the current PL_LEGEND_CMAP0 and PL_LEGEND_CMAP1 flags in opt_array with PL_LEGEND_DISCRETE_COLOR. > 3. In the 5.9.7 release thread you mentioned the ability to skip > entries when using pllegend interactively. Could this be specified > explicitly? Should there be a PL_LEGEND_NONE option defined (= 0 I > think) for opt_array? This isn't strictly necessary as passing 0 > would do the same thing, but it would make the intent of code using > this skipping functionality a bit easier to see. PL_LEGEND_NONE > wouldn't need a special case in the pllegend implementation, just a > #define along with the other PL_LEGEND_* options. Good catch. Fixed as of revision 11230. > > I like pllegend in its current state overall. I do, however, think > that it is worth encouraging the PLplot developers and interested > users to try out the pllegend API post-5.9.7 before we commit to > keeping the API as-is. In particular, some real-world use and a > plcolorbar implementation may expose other options we would like to > provide in pllegend. Agreed. (See my post in the 5.9.7 thread on this issue.) So it appears the only outstanding issue is issue 2, mentioned above. Your quick feedback on that (especially the generic pointer possibility to halve the colour arguments) would be much appreciated. 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: Schwab,Wilhelm K <bs...@an...> - 2010-09-28 18:12:40
|
RE map0 vs. 1, with the understanding that I have no idea what I am talking about, the maps are global, right? Could the answer be to pass a function pointer instead of the array? That would get around the void pointer because the common denominator would instead be a function that translates colors, not the colors themselves. There would hopefully be only two of them that are part of the library and hide any details. Sorry if that's missing the point(er). Bill -----Original Message----- From: Alan W. Irwin [mailto:ir...@be...] Sent: Tuesday, September 28, 2010 1:03 PM To: Hezekiah M. Carty Cc: PLplot development list Subject: Re: [Plplot-devel] Volunteer requested to implement legend-drawing capability for the PLplot core library. On 2010-09-28 08:43-0400 Hezekiah M. Carty wrote: > On Sun, Sep 26, 2010 at 12:50 AM, Alan W. Irwin > <ir...@be...> wrote: >> On 2010-09-25 15:32-0700 Alan W. Irwin wrote: >>> and then move on to designing and >>> implementing the cmap1 part of that API (after reviewing your ideas >>> on >>> that) by early next week assuming it fits in nicely with pllegend. >> >> I plan to start on the cmap1 part tomorrow (Sunday). I feel >> confident the end result will be a powerful legend capability for >> PLplot that should satisfy virtually everybody's legend needs. >> > > Aside from the question about the cmap[01]_colors, cmap_patterns, > cmap_scales questions I brought up in the 5.9.7 release thread, my > main concerns come down to types: > > 1. text_justification is defined as a PLINT, but from the doxygen > documentation it looks like it should be a PLFT. Good catch! Fixed as of revision 11230. > 2. With support for cmap1 elsewhere in pllegend, would it be > reasonable to add support for cmap1 line and symbol colors? Yes. > Do people > generally use cmap1 for line or symbol plots? I think we only have one instance of that in our examples so users may not have picked up on this possibility, but it has long been the case that plcol0 and plcol1 could be used interchangably so perhaps we should arrange that for pllegend as well. To implement this, I think we need an overall PL_LEGEND_CMAP1 opt flag and we should replace PL_LEGEND_CMAP0 and PL_LEGEND_CMAP1 in opt_array with PL_LEGEND_DISCRETE_COLOR. If the overall PL_LEGEND_CMAP1 opt flag is set, _all_ color indices are interpreted as PLFLT cmap1 values in the range from 0. to 1., but otherwise they are interpreted as PLINT cmap0 index values. One potential downside to having cmap0 and cmap1 alternatives for all colors is a proliferation of alternative PLINT cmap0 or PLFLT cmap1 arguments such as the current PLINT *cmap0_colors, PLFLT * cmap1_colors arguments. Could we just use generic pointer (void *) arguments to stand in for either kind of cmap index/value to halve the number of color arguments? I have very little experience with using void *, so if you think this idea would work, could you illustrate what to do with a commit that replaces the current PLINT *cmap0_colors, PLFLT * cmap1_colors arguments with one generic pointer argument? Then I could propagate that idea to all our other color arguments, e.g., bg_color, text_colors, line_colors, symbol_colors (which are currently restricted to just cmap0). Are there any downsides to using generic pointers for something like this? For example, will such pointers make it difficult to propagate pllegend to some of our languages? Whatever we decide to do here, I think we should be consistent. So if you don't think it is a good idea to provide both cmap0 and cmap1 alternatives for all colour arguments (through generic pointers), then I think we should probably consistently use cmap0 arguments for all colors, i.e., drop the PLFLT * cmap1_colors argument and replace the current PL_LEGEND_CMAP0 and PL_LEGEND_CMAP1 flags in opt_array with PL_LEGEND_DISCRETE_COLOR. > 3. In the 5.9.7 release thread you mentioned the ability to skip > entries when using pllegend interactively. Could this be specified > explicitly? Should there be a PL_LEGEND_NONE option defined (= 0 I > think) for opt_array? This isn't strictly necessary as passing 0 > would do the same thing, but it would make the intent of code using > this skipping functionality a bit easier to see. PL_LEGEND_NONE > wouldn't need a special case in the pllegend implementation, just a > #define along with the other PL_LEGEND_* options. Good catch. Fixed as of revision 11230. > > I like pllegend in its current state overall. I do, however, think > that it is worth encouraging the PLplot developers and interested > users to try out the pllegend API post-5.9.7 before we commit to > keeping the API as-is. In particular, some real-world use and a > plcolorbar implementation may expose other options we would like to > provide in pllegend. Agreed. (See my post in the 5.9.7 thread on this issue.) So it appears the only outstanding issue is issue 2, mentioned above. Your quick feedback on that (especially the generic pointer possibility to halve the colour arguments) would be much appreciated. 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 __________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Plplot-devel mailing list Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2010-11-03 07:56:50
|
Hi Hez: I have made some additional progress with pllegend as of revision 11304. On 2010-10-17 23:03-0700 Alan W. Irwin wrote: > On 2010-10-17 21:28-0400 Hezekiah M. Carty wrote: > >> On Sun, Oct 17, 2010 at 3:12 PM, Hezekiah M. Carty > >>> One suggestion I have for the API is to add a box/outline option for >>> the pllegend window (PL_LEGEND_BOX as another option for the opt >>> parameter?). > > I think this is a good idea. The independent QSAS plot legend also > has the option of painting a bounding box for the legend. DONE both with colour and linestyle capabilities. > [out of order] I am thinking of an API > where you specify nrow and ncolumn. Normally, the nrow by ncolumn > cells would be filled in column-major order with nlegend <= > nrow*ncolumn entries, but if the PL_LEGEND_ROW_MAJOR bit were set, the > cell filling would be done in row-major order rather than the default > column-major order. DONE as described. Items I hope to implement in the next day or so: 1. Specify the x, y position and length of plotted area in normalized viewport coordinates rather than the current normalized sub-page coordinates. Of course, despite this change in coordinates, the results will still be clipped at the sub-page boundary rather than viewport boundary. 2. Implement plstring(n, x, y, string) API to write string (normally just one glyph) at the specified array of x, y points. Note, string is a normal PLplot user-input string including the possibility of UTF-8 (including the ascii subset of that) and the normal PLplot text escape sequences. plstring is planned to be a fully unicode-aware replacement for plsymbol and plpoin. Use plstring to render the symbols used for the green lines in examples 4 and 26. 3. Replace plpoin symbol indices with strings in pllegend, and use plstring internally in pllegend to render those strings with corresponding examples 4 and 26 legend changes. 4. (after further discussion with you). >> I think it is worth considering different ways of expressing the >> position of a legend or color bar. For example, in the OCaml color >> bar API, the position of the color bar is specified relative to a >> user-specified plot subpage boundary. This could be done in the C API >> with another set of options for the "opt" parameter: PL_LEGEND_TOP, >> PL_LEGEND_BOTTOM, PL_LEGEND_LEFT, PL_LEGEND_RIGHT and possibly >> PL_LEGEND_CENTER. The position arguments would then be interpreted as >> offsets from the given side. For example: >> >> PL_LEGEND_BOTTOM | PL_LEGEND_RIGHT : Position the box relative to the >> bottom-right of the plot subpage >> >> PL_LEGEND_RIGHT | PL_LEGEND_CENTER : Position the box relative to the >> right side of the plot subpage, centered vertically (the y-position >> would be ignored in this case) >> >> The default would continue to be PL_LEGEND_TOP | PL_LEGEND_LEFT. I >> expect PL_LEGEND_CENTER to be more commonly used with plcolorbar. The QSAS team uses a number of fixed legend positions e.g., "inside top right" would place the top right corner of the legend coincident with the top right corner of the viewport while "inside bottom left" would place the bottom left corner of the legend coincident with the bottom left of the viewport. They also have "inside top left", "inside bottom right", "above top centre", and "outside top right". I am not exactly sure of the exact definition/usefulness of the last two. They also allow a customized position like we have now. I think I prefer the QSAS legend position ideas over your idea above of changing the origin of the custom coordinates. The fixed positions will be useful, and it is more straightforward for users to have a consistent origin for the customized positions (especially when the values at the edges of the viewport are either 0. or 1.). However, it is important to come to consensus about this since we want the same position options for your plcolorbar so I look forward to your response to the QSAS legend position ideas. 5. doxygen and docbook documentation changes to reflect the above changes to pllegend. 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: Andrew R. <and...@us...> - 2010-11-04 11:10:59
|
On Wed, Nov 03, 2010 at 12:56:40AM -0700, Alan Irwin wrote: > Hi Hez: > > I have made some additional progress with pllegend as of revision 11304. > > 4. (after further discussion with you). > > >> I think it is worth considering different ways of expressing the > >> position of a legend or color bar. For example, in the OCaml color > >> bar API, the position of the color bar is specified relative to a > >> user-specified plot subpage boundary. This could be done in the C API > >> with another set of options for the "opt" parameter: PL_LEGEND_TOP, > >> PL_LEGEND_BOTTOM, PL_LEGEND_LEFT, PL_LEGEND_RIGHT and possibly > >> PL_LEGEND_CENTER. The position arguments would then be interpreted as > >> offsets from the given side. For example: > >> > >> PL_LEGEND_BOTTOM | PL_LEGEND_RIGHT : Position the box relative to the > >> bottom-right of the plot subpage > >> > >> PL_LEGEND_RIGHT | PL_LEGEND_CENTER : Position the box relative to the > >> right side of the plot subpage, centered vertically (the y-position > >> would be ignored in this case) > >> > >> The default would continue to be PL_LEGEND_TOP | PL_LEGEND_LEFT. I > >> expect PL_LEGEND_CENTER to be more commonly used with plcolorbar. > > The QSAS team uses a number of fixed legend positions e.g., "inside top > right" would place the top right corner of the legend coincident with > the top right corner of the viewport while "inside bottom left" would > place the bottom left corner of the legend coincident with the bottom > left of the viewport. They also have "inside top left", "inside > bottom right", "above top centre", and "outside top right". I am not > exactly sure of the exact definition/usefulness of the last two. They > also allow a customized position like we have now. > > I think I prefer the QSAS legend position ideas over your idea above > of changing the origin of the custom coordinates. The fixed positions > will be useful, and it is more straightforward for users to have a > consistent origin for the customized positions (especially when the > values at the edges of the viewport are either 0. or 1.). However, it > is important to come to consensus about this since we want the same > position options for your plcolorbar so I look forward to your > response to the QSAS legend position ideas. Gnuplot also use a similar generic positioning for legends (i.e. top left) which works well in my experience. They also provide for fine-grained positioning by setting the coordinates of the legend (in plot coordinates). I think this approach works well. 95% of the time the general approach is sufficient, and means things work even if the axes etc change, however I do find the fine-grained control necessary on occasions to minimise interference between the plot and the legend. I agree with Alan, that fixed positions for the custom origin are better. You can argue whether you want them in relative coordinates (i.e. 0-1) or in the current axis coordinates. Probably relative I think, although there are arguments each way. Andrew |
From: Alan W. I. <ir...@be...> - 2010-11-04 20:22:08
|
On 2010-11-04 11:10-0000 Andrew Ross wrote: > Gnuplot also use a similar generic positioning for legends (i.e. top left) > which works well in my experience. They also provide for fine-grained > positioning by setting the coordinates of the legend (in plot coordinates). > I think this approach works well. 95% of the time the general approach is > sufficient, and means things work even if the axes etc change, however > I do find the fine-grained control necessary on occasions to minimise > interference between the plot and the legend. I agree with Alan, that > fixed positions for the custom origin are better. You can argue whether > you want them in relative coordinates (i.e. 0-1) or in the current > axis coordinates. Probably relative I think, although there are arguments > each way. Hi Andrew: Thanks for your input. I have been in touch with Hez off list about another better idea I had, and with one further change we have come to consensus on that idea which is similar to what you have stated above. Here are the details of that idea. Define PL_LEGEND_TOP PL_LEGEND_BOTTOM PL_LEGEND_LEFT PL_LEGEND_RIGHT PL_LEGEND_OUTSIDE PL_LEGEND_INSIDE where LEFT alone means middle LEFT, TOP alone means middle TOP, etc. The corners would be specified by the appropriate combination (e.g., LEFT and TOP) of two of the bits. So with various combinations of these bits we can specify any one of the 4 corners or 4 middle positions of each side of the viewport as the zero point of the coordinate system regardless of the value of OUTSIDE or INSIDE. The interpretation of TOP, BOTTOM, LEFT, or RIGHT depends on INSIDE or OUTSIDE when simultanously specifying the reference point of the legend using the above bits. For example, for LEFT, TOP, INSIDE the zero point would be the left top of the viewport and the reference point would be the left top of the legend. The OUTSIDE flag gives 8 more possibilities for the reference point on the opposite side of the legend for a total of 16 standard positions. For example, for LEFT, TOP, OUTSIDE the zero point would be the left top of the viewport (as for the INSIDE case) and the reference point would be the bottom right of the legend. Each of these 16 standard positions for the legend could be customized by specifying x and y offset values (both positive and negative), but often you would just take zero for both x and y to conform to one of the standard 16 positions. Of course, illegal combinations of bits (e.g., PL_LEGEND_OUTSIDE and PL_LEGEND_INSIDE or PL_LEGEND_LEFT and PL_LEGEND_RIGHT) will generate a warning and immediate return from pllegend. I hope to start implementing this positioning scheme for pllegend later today, and Hez plans to also use this positioning scheme for plcolorbar (in a couple of weeks once he has time to deal with that). 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: Alan W. I. <ir...@be...> - 2010-11-06 00:33:41
|
On 2010-11-04 13:22-0700 Alan W. Irwin wrote: > On 2010-11-04 11:10-0000 Andrew Ross wrote: > >> Gnuplot also use a similar generic positioning for legends (i.e. top left) >> which works well in my experience. They also provide for fine-grained >> positioning by setting the coordinates of the legend (in plot coordinates). >> I think this approach works well. 95% of the time the general approach is >> sufficient, and means things work even if the axes etc change, however >> I do find the fine-grained control necessary on occasions to minimise >> interference between the plot and the legend. I agree with Alan, that >> fixed positions for the custom origin are better. You can argue whether >> you want them in relative coordinates (i.e. 0-1) or in the current >> axis coordinates. Probably relative I think, although there are arguments >> each way. > > Hi Andrew: > > Thanks for your input. I have been in touch with Hez off list about > another better idea I had, and with one further change we have come to > consensus on that idea which is similar to what you have stated above. > Here are the details of that idea. > > Define > > PL_LEGEND_TOP > PL_LEGEND_BOTTOM > PL_LEGEND_LEFT > PL_LEGEND_RIGHT > PL_LEGEND_OUTSIDE > PL_LEGEND_INSIDE > > where LEFT alone means middle LEFT, TOP alone means middle TOP, etc. > The corners would be specified by the appropriate combination (e.g., > LEFT and TOP) of two of the bits. So with various combinations of > these bits we can specify any one of the 4 corners or 4 middle > positions of each side of the viewport as the zero point of the > coordinate system regardless of the value of OUTSIDE or INSIDE. The > interpretation of TOP, BOTTOM, LEFT, or RIGHT depends on INSIDE or > OUTSIDE when simultanously specifying the reference point of the > legend using the above bits. For example, for LEFT, TOP, INSIDE the > zero point would be the left top of the viewport and the reference > point would be the left top of the legend. The OUTSIDE flag gives 8 > more possibilities for the reference point on the opposite side of the > legend for a total of 16 standard positions. For example, for LEFT, > TOP, OUTSIDE the zero point would be the left top of the viewport (as > for the INSIDE case) and the reference point would be the bottom right > of the legend. Each of these 16 standard positions for the legend > could be customized by specifying x and y offset values (both positive > and negative), but often you would just take zero for both x and y to > conform to one of the standard 16 positions. Of course, illegal > combinations of bits (e.g., PL_LEGEND_OUTSIDE and PL_LEGEND_INSIDE or > PL_LEGEND_LEFT and PL_LEGEND_RIGHT) will generate a warning and > immediate return from pllegend. > This has now (revision 11309) been implemented (with PL_LEGEND_TOP and PL_LEGEND_BOTTOM renamed to PL_LEGEND_UPPER and PL_LEGEND_LOWER) in the static legend_position routine which should be reusable for plcolorbar when Hez implements that. The logic in that routine includes calculation of the sign of the x, y offsets depending on the PL_LEGEND position bits that have been set. I have tested all 16 standard positions, but I have only done limited testing of the sign logic. I have also changed the interpretation of x, y, and plot_width from normalized subpage coordinates to normalized viewport coordinates. I have also done a whole lot of renaming of variables to make them correspond more closely to their units (normally relative subpage units). My remaining pllegend ToDo: 1. Implement plstring and also use it internally in pllegend rather than the legacy plsym. 2. Documentation (doxygen and docbook) of pllegend To finish off our legend-related work three additional projects have to be completed. 1. plcolorbar (Hez). 2. String-length calculations done properly for the qt device driver similar to the way they have been done for the cairo device driver (Hazen). 3. Propagation of plcolorbar, pllegend, and plstring to all our languages (everybody). Once all of this is done, I think we will have some pretty awesome (legendary?) legend capability. 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 __________________________ |