On Sat, Sep 11, 2010 at 4:56 PM, Alan W. Irwin
<irwin@...> wrote:
> On 2010-09-11 00:47-0400 Hezekiah M. Carty wrote:
>
>> On Fri, Sep 10, 2010 at 9:09 PM, Alan W. Irwin
>> <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.
>>>
>>> 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

On Fri, Jul 16, 2010 at 10:53 AM, Steve Schwartz
<s.schwartz@...> wrote:
> Hi Hez,
>
> I've found a couple of bugs in your plarc routine which I've also fixed,
> but since this is your code I'll leave you to look over it and commit
> as/when necessary. There were 3 bugs in your plarc_approx routine.
> Looking through the devices, it seems that with the exception of the
> cairo devices, all the others don't drive any native arc-drawing and so
> drop into your approx version. [I guess most/all ps and pdf, and svg,
> devices probably know how to draw an arc, so I guess these drivers could
> be modified, but that's another story. The approx version is perfectly
> adequate for most purposes.]
>
Steve,
Thank you for providing these fixes! I'm sorry it took so long, but
as of revision 11192 you patch has been applied. The example program
you provided now shows the same output for each of the plot pages,
regardless of the device used.
Part of the reasoning behind adding the plarc function was that so
many of our devices support native arc primitives. I doubt that I
will have a chance to add device-level support, but hopefully the
plarc support in the Cairo device family will provide a reasonable
reference for others to work from.
Thank you again for the report and fix!
Hez