On Sat, Sep 11, 2010 at 4:56 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> 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...@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. >
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
<<attachment: image_colorbar_example.png>>
------------------------------------------------------------------------------ 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
