On 2010-09-11 00:47-0400 Hezekiah M. Carty wrote: > On Fri, Sep 10, 2010 at 9:09 PM, Alan W. Irwin > <ir...@beluga.phys.uvic.ca> 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 __________________________ ------------------------------------------------------------------------------ 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 Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
