Re: [Plplot-devel] Volunteer requested to implement legend-drawing capability for the PLplot core library.

[Alan W. I. <ir...@be...>]

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
__________________________