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

2010-12-27 Thread Hezekiah M. Carty
On Sun, Nov 14, 2010 at 3:26 AM, Alan W. Irwin
ir...@beluga.phys.uvic.ca wrote:
 On 2010-11-10 13:46-0800 Alan W. Irwin wrote:

 Other's legend-related work for this release cycle:

 * plcolorbox (Hez).


It's taken much longer than expected, but a first (incomplete) version
of plcolorbar is now available (revision 11394).  The commit message
has more details, but here is a summary.

The eventual plan is to support color bars for plimage, possibly
plimagefr, plshades and probably plgradient with this function.  This
revision only includes support for plimage.  Color bars can be placed
relative to any of the four plot sub-page sides, with user-defined
lengths and widths.  End-caps can be added as well.

Two pages have been added to the end of example 33 to illustrate the
progress so far.  There is still a lot of testing to do, particularly
testing all of the possible combinations of position side, label side
and end-cap drawing.

Please take a look at the API and new pages from example 33 and let me
know if anything seems to be missing or implemented in an unintuitive
way.

Enjoy!

Hez

--
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel


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

2010-11-14 Thread Alan W. Irwin
On 2010-11-10 13:46-0800 Alan W. Irwin wrote:

 On 2010-11-09 14:15-0800 Alan W. Irwin wrote:

 In other words, I think plstring and pllegend are ready for
 propagation to bindings and examples 4 and 26 for all languages.

 Wrong again  :-)

And yet again :-)

revision 11328 changes the API by adding a box_line_widths array to
the argument list.  See commit message for justification.

I use this argument in one of the calls to pllegend in the new 4th
page of example 33 which put the different legend types that are
possible with pllegend through their various paces.  (This page caught
a few bugs in pllegend which I also fixed in revision 11328.)

In an earlier commit I also revised the 3rd page of example 33 to
look a bit nicer.  I believe I am now done with example 33
which implies I wont be messing with the pllegend argument
list any more (he says for the third time!).

Here is what is remaining on my pllegend (and related) ToDo list for this 
release cycle
(in descending order of priority):

* Propagate example 33 from Python to C.

* Doxygen and DocBook documentation of the API.

* Each set of pllegend argument arrays describing text, boxes, lines,
or symbols has different numbers and/or different types of arrays. 
Thus, it should be possible to implement 2^4 = 16 overloaded variations
(for languages that support overloading) of pllegend that use the 2^4
combinations of each set of pllegend argument arrays dropped or not.

* Default values of most of the pllegend arguments if they are not
supplied by the user or invalid values are supplied by the user. (This
has already been done with nrow and ncolumn, but the idea should
be greatly expanded.)

* Debug the %%*%*(* vertical alignment issues that are
demonstrated (with different offsets for the many different kinds of
text handling that are used by our device drivers) by examples 4, 26,
and 33 and also by the later pages of examples/python/test_circle.py.

It's quite likely some of the issues near the end of the above ToDo
list will have to be put off until the next release cycle since I have
promised some research colleagues that I will put some quality time
into FreeEOS in the near future.

Other's legend-related work for this release cycle:

* plcolorbox (Hez).

* string-length calculations implemented for our qt device driver
similar to what has already been done for our cairo device driver
(Hazen).

* Propagation of pllegend bindings and changed examples (4 and 26) and
new example (33) to all our languages other than C and Python.
(Presumably most active developers will help with this propagation for
their favorite language once I have completed the C version of example
33.)

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
__

--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel


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

2010-11-10 Thread Alan W. Irwin
On 2010-11-09 14:15-0800 Alan W. Irwin wrote:

 In other words, I think plstring and pllegend are ready for
 propagation to bindings and examples 4 and 26 for all languages.

Wrong again  :-)

Revision 11318 changed the pllegend API again (and also changed the
Python bindings and C and Python examples accordingly).  The
motivation for that change is I would like to demonstrate multiple
legends aligned with each other for example 33, and for such alignment
you need to make the legend_width and legend_height calculated by
pllegend accessible to the calling routine.

I urge developers and users here to test pllegend capabilities
immediately by modifying the Python (especially example 33) or C
examples.  That immediately is because we want to finalize the
pllegend API as early as possible in this release cycle.  I am
actually pretty sure that API is finalized now, but we might be
blindsided by additional needs late in this release cycle or even in
the next release cycle unless you all immediately do some inventive
testing and/or thinking about how pllegend will be used in the future.

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
__

--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book Blueprint to a 
Billion shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel


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

2010-11-09 Thread Alan W. Irwin
On 2010-11-05 17:33-0700 Alan W. Irwin wrote:

 My remaining pllegend ToDo:

 1. Implement plstring and also use it internally in pllegend rather
 than the legacy plsym.

DONE as of revision 11310.  There is still plstring and pllegend
documentation work, vertical offset debugging for plptex, and
plcolorbar and qt device driver plstrl work to do, but this commit
constitutes the last API change I have planned for pllegend so this
should be the final API.  This should also be the final form of API
for plstring.

In other words, I think plstring and pllegend are ready for
propagation to bindings and examples 4 and 26 for all languages.  I
plan to do the python propagation shortly, and I hope others will help
with the propagation effort for other languages.

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
__

--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book Blueprint to a 
Billion shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel


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

2010-11-09 Thread Alan W. Irwin
On 2010-11-09 14:15-0800 Alan W. Irwin wrote:

 In other words, I think plstring and pllegend are ready for
 propagation to bindings and examples 4 and 26 for all languages.  I
 plan to do the python propagation shortly []

Python propagation of plstring and pllegend to bindings and examples
DONE as of revision 11312.

Java and Lua propagation of plstring (but not pllegend) to bindings
and examples DONE as of revision 11313. Andrew, would you be willing
to finish propagation of pllegend for Python?  Werner, would you be
willing to do the same for Lua?  I cannot finish those because I don't
know how to handle swig conversion of const char** arguments in either
language.

My next step is to make a standard example 33 (first in the Python
language but then to be propagated to all other languages) that will
exercise many different pllegend capabilities.

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
__

--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book Blueprint to a 
Billion shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel


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

2010-11-05 Thread Alan W. Irwin
On 2010-11-04 13:22-0700 Alan W. Irwin wrote:

 On 2010-11-04 11:10- 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
__

--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book Blueprint to a 
Billion shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev

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

2010-11-04 Thread Andrew Ross
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

--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book Blueprint to a 
Billion shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel


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

2010-11-04 Thread Alan W. Irwin
On 2010-11-04 11:10- 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
__

--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book Blueprint to a 
Billion shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel


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

2010-11-03 Thread Alan W. Irwin
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
__

--
Achieve Improved Network Security with IP and DNS Reputation.
Defend against bad network traffic, including botnets, malware, 
phishing sites, and compromised hosts - saving your company time, 
money, and embarrassment.   Learn More! 
http://p.sf.net/sfu/hpdev2dev-nov
___
Plplot-devel mailing list

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

2010-10-18 Thread Alan W. Irwin
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.

 I'm not sure how the color of the box should be added to
 the API - we already get a background color argument, and I'm
 concerned about pllegend's already long argument list becoming longer
 with every new option added.

I would go ahead and add another argument to specify the color of the
box.  I think we just have to live with the fact that making a legend
that satisfies most people's style requirements requires a lot of
arguments (see also nrow and ncolumn discussed below).  However, large
numbers of arguments shouldn't be much of a problem for C users if we
are really smart about adopting good default values for most
parameters.  Furthermore, we will eventually want to provide some
standard smaller argument lists for pllegend for those language
bindings that have function overloading.  So let's keep these general
possibilities in mind, but wait to do any detailed implemention of
default values and/or function overloading until the fundamental
API is completely settled.



 I have started work on the plcolorbar API.  I don't expect to have it
 done today, but it did bring up some API/functionality changes I would
 like to propose for pllegend (and use in plcolorbar).

 1. 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.

Sounds good.

 2. Allow a user to specify if they want the legend positioned relative
 to the plot window or the plot subpage (PL_LEGEND_PAGE or
 PL_LEGEND_WINDOW?).  The position would be (possibly normalized) plot
 window coordinates for PL_LEGEND_WINDOW and normalized subpage
 coordinates for PL_LEGEND_PAGE.  Sizes/lengths would probably still be
 specified as normalized subpage coordinates.

The QSAS team brought up this issue as well.  I think you guys are
right so let's just drop the PL_LEGEND_PAGE and PL_LEGEND_WINDOW
control bits and instead always specify the x, y position, and length
of plotted area in normalized window coordinates.  Then to go outside
the window you simply set an x position or y position of less than 0
or greater than 1.


 I expect most of the opt-appropriate options to be shared between
 pllegend and plcolorbar.

 If the rest of you feel that these changes are reasonable, I am
 willing to make or help make the required changes to the C
 implementation of pllegend.

Please go ahead.

After you have completed those C API changes, there is one additional
change (rows and columns in the legend, again suggested by what the
QSAS legend does) that I want to implement as well.  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.

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
__

--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev

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

2010-10-17 Thread Hezekiah M. Carty
On Mon, Oct 4, 2010 at 9:36 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
 As of revision 11247 I have propagated the pllegend API to python just
 to prove that I could do so.  Because my python swig skills are rusty
 it was a bit of a struggle dealing with the char ** text array because
 we had not dealt with that type before with swig.  Those who
 eventually propagate pllegend to Java and Lua (and probably other
 languages) should be aware that this type is going to cause you some
 extra work.

 As a result of my propagation work, I now get consistent results for
 python and C for both examples 4 and 26.  Others may also want to
 propagate pllegend to their favorite languages at this time.  However,
 you should be aware that once Hez and Andrew have propagated pllegend
 to OCaml and Octave and compared its capabilities with the older
 legend capabilities for those languages, we might get some suggested
 changes in the pllegend API out of those comparisons.  If those
 changes actually occur I am willing to modify my python propagation
 accordingly, but others may want to wait to propagate pllegend until
 we get feedback from Hez and Andrew on their experiences with pllegend
 for OCaml and Octave.


I have propagated the pllegend API and example changes (examples 4 and
26) to OCaml as of revision 11262.  This revision gives clean make
test_diff_psc results between C and OCaml on my system.

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'm not sure how the color of the box should be added to
the API - we already get a background color argument, and I'm
concerned about pllegend's already long argument list becoming longer
with every new option added.

The previous OCaml legend support does not have this feature, but it
would be a nice addition.

 We also need a volunteer to create an initial version of plcolorbar
 functionality in our core C library to complement the current discrete
 pllegend functionality. Hez, would you also be willing/able to take a
 shot at this?


I'll see what I can do with this.

Hez

--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel


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

2010-10-17 Thread Hezekiah M. Carty
On Sun, Oct 17, 2010 at 3:12 PM, Hezekiah M. Carty
hezekiahca...@users.sourceforge.net wrote:
 On Mon, Oct 4, 2010 at 9:36 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca 
 wrote:

 As a result of my propagation work, I now get consistent results for
 python and C for both examples 4 and 26.  Others may also want to
 propagate pllegend to their favorite languages at this time.  However,
 you should be aware that once Hez and Andrew have propagated pllegend
 to OCaml and Octave and compared its capabilities with the older
 legend capabilities for those languages, we might get some suggested
 changes in the pllegend API out of those comparisons.  If those
 changes actually occur I am willing to modify my python propagation
 accordingly, but others may want to wait to propagate pllegend until
 we get feedback from Hez and Andrew on their experiences with pllegend
 for OCaml and Octave.


 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'm not sure how the color of the box should be added to
 the API - we already get a background color argument, and I'm
 concerned about pllegend's already long argument list becoming longer
 with every new option added.


I have started work on the plcolorbar API.  I don't expect to have it
done today, but it did bring up some API/functionality changes I would
like to propose for pllegend (and use in plcolorbar).

1. 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.

2. Allow a user to specify if they want the legend positioned relative
to the plot window or the plot subpage (PL_LEGEND_PAGE or
PL_LEGEND_WINDOW?).  The position would be (possibly normalized) plot
window coordinates for PL_LEGEND_WINDOW and normalized subpage
coordinates for PL_LEGEND_PAGE.  Sizes/lengths would probably still be
specified as normalized subpage coordinates.

I expect most of the opt-appropriate options to be shared between
pllegend and plcolorbar.

If the rest of you feel that these changes are reasonable, I am
willing to make or help make the required changes to the C
implementation of pllegend.

Hez

--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel


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

2010-10-04 Thread Alan W. Irwin
As of revision 11247 I have propagated the pllegend API to python just
to prove that I could do so.  Because my python swig skills are rusty
it was a bit of a struggle dealing with the char ** text array because
we had not dealt with that type before with swig.  Those who
eventually propagate pllegend to Java and Lua (and probably other
languages) should be aware that this type is going to cause you some
extra work.

As a result of my propagation work, I now get consistent results for
python and C for both examples 4 and 26.  Others may also want to
propagate pllegend to their favorite languages at this time.  However,
you should be aware that once Hez and Andrew have propagated pllegend
to OCaml and Octave and compared its capabilities with the older
legend capabilities for those languages, we might get some suggested
changes in the pllegend API out of those comparisons.  If those
changes actually occur I am willing to modify my python propagation
accordingly, but others may want to wait to propagate pllegend until
we get feedback from Hez and Andrew on their experiences with pllegend
for OCaml and Octave.

We also need a volunteer to create an initial version of plcolorbar
functionality in our core C library to complement the current discrete
pllegend functionality. Hez, would you also be willing/able to take a
shot at 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
__

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2  L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel


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

2010-10-01 Thread Alan W. Irwin
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
__

--
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


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

2010-09-30 Thread Hezekiah M. Carty
On Thu, Sep 30, 2010 at 1:56 AM, Alan W. Irwin
ir...@beluga.phys.uvic.ca 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

--
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


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

2010-09-29 Thread Hezekiah M. Carty
On Tue, Sep 28, 2010 at 6:46 PM, Alan W. Irwin
ir...@beluga.phys.uvic.ca wrote:
 On 2010-09-28 14:30-0700 Alan W. Irwin wrote:

 For the simplest is best reasons [...], I am going to drop cmap1
 from pllegend.  I will try to finish that by late this afternoon.

 Done as of revision 11231.


While working on the OCaml interface to pllegend, I came up with a
potential improvement to the C interface:

What do you think of changing the pllegend API somewhat to allow only
specifying the entries which are actually used?  For example, if there
are no symbols, the symbol arrays would be empty.  If there are two
lines and one box, there would be two elements in the line arrays and
one in the box array.  nlegend would still be the total number of
entries in the legend, and opt_array would be used to specify where
the legend entries are placed.

Here is a example subset of parameters:

nlegend: 4
opt_array: PL_LEGEND_LINE, PL_LEGEND_LINE, PL_LEGEND_SYMBOL |
PL_LEGEND_LINE, PL_LEGEND_LINE
line_colors: red, blue, purple, green
symbol_colors: blue, yellow

From these (plus styles, widths, symbols, etc), the legend would show up as:

1. blue symbols, red line
2. blue line
3. yellow symbols, purple line
4. green line

Does this make sense?  I think it would make passing arguments to
pllegend a bit more predictable as no dummy entries are required, but
I don't know if others would feel the same way.

I'm willing to make an attempt at implementation if you think it is
worth considering.

Hez

--
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


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

2010-09-29 Thread Hezekiah M. Carty
On Wed, Sep 29, 2010 at 9:40 PM, Hezekiah M. Carty
hezekiahca...@users.sourceforge.net wrote:
 On Tue, Sep 28, 2010 at 6:46 PM, Alan W. Irwin
 ir...@beluga.phys.uvic.ca wrote:
 On 2010-09-28 14:30-0700 Alan W. Irwin wrote:

 For the simplest is best reasons [...], I am going to drop cmap1
 from pllegend.  I will try to finish that by late this afternoon.

 Done as of revision 11231.


 While working on the OCaml interface to pllegend, I came up with a
 potential improvement to the C interface:

snip

 I'm willing to make an attempt at implementation if you think it is
 worth considering.


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?

Hez
diff --git a/examples/c/x04c.c b/examples/c/x04c.c
index c3abc75..13621c1 100644
--- a/examples/c/x04c.c
+++ b/examples/c/x04c.c
@@ -129,26 +129,24 @@ plot1( int type )
 line_styles[1]= 1;
 line_widths[0]= 1;
 line_widths[1]= 1;
-symbol_colors[0]  = 2;
-symbol_colors[1]  = 3;
-symbol_scales[0]  = 1.2;
-symbol_scales[1]  = 1.;
-symbol_numbers[0] = 3;
-symbol_numbers[1] = 4;
+symbol_colors[0]  = 3;
+symbol_scales[0]  = 1.;
+symbol_numbers[0] = 4;
 symbols[0]= 3;
-symbols[1]= 3;
+/*
 box_colors[0] = 2;
 box_colors[1] = 3;
 box_patterns[0]   = 0;
 box_patterns[1]   = 3;
 box_scales[0] = 0.5;
 box_scales[1] = 0.5;
+*/
 plscol0a( 15, 32, 32, 32, 0.90 );
 pllegend( PL_LEGEND_BACKGROUND, 0.57, 0.85, 0.06, 15,
 nlegend, opt_array,
 1.0, 1.0, 2.0,
 1., text_colors, text,
-box_colors, box_patterns, box_scales,
+NULL, NULL, NULL,
 line_colors, line_styles, line_widths,
 symbol_colors, symbol_scales, symbol_numbers, symbols );
 }
diff --git a/src/pllegend.c b/src/pllegend.c
index dc664a4..5888264 100644
--- a/src/pllegend.c
+++ b/src/pllegend.c
@@ -199,6 +199,9 @@ c_pllegend( PLINT opt, PLFLT x, PLFLT y, PLFLT plot_width, PLINT bg_color,
 // Saved normalized coordinates of viewport.
 PLFLT xdmin_save, xdmax_save, ydmin_save, ydmax_save;
 
+// Counters to keep track of where we are in the legend progression
+PLINT box_index = 0, line_index = 0, symbol_index = 0;
+
 PLFLT x_world_per_mm, y_world_per_mm, text_width0 = 0., text_width;
 PLFLT total_width_border, total_width, total_height;
 
@@ -342,37 +345,43 @@ c_pllegend( PLINT opt, PLFLT x, PLFLT y, PLFLT plot_width, PLINT bg_color,
 {
 if ( opt_array[i]  PL_LEGEND_COLOR_BOX )
 {
-plcol0( box_colors[i] );
-plpsty( box_patterns[i] );
-ybox[0] = ty + 0.5 * dty * box_scales[i];
-ybox[1] = ty - 0.5 * dty * box_scales[i];
-ybox[2] = ty - 0.5 * dty * box_scales[i];
-ybox[3] = ty + 0.5 * dty * box_scales[i];
+plcol0( box_colors[box_index] );
+plpsty( box_patterns[box_index] );
+ybox[0] = ty + 0.5 * dty * box_scales[box_index];
+ybox[1] = ty - 0.5 * dty * box_scales[box_index];
+ybox[2] = ty - 0.5 * dty * box_scales[box_index];
+ybox[3] = ty + 0.5 * dty * box_scales[box_index];
 plfill( 4, xbox, ybox );
+// Increment the box index counter
+box_index++;
 }
 if ( opt_array[i]  PL_LEGEND_LINE )
 {
-plcol0( line_colors[i] );
-pllsty( line_styles[i] );
-plwid( line_widths[i] );
+plcol0( line_colors[line_index] );
+pllsty( line_styles[line_index] );
+plwid( line_widths[line_index] );
 yl[0] = ty;
 yl[1] = ty;
 plline( 2, xl, yl );
 pllsty( line_style_save );
 plwid( line_width_save );
+// Increment the line index counter
+line_index++;
 }
 
 if ( opt_array[i]  PL_LEGEND_SYMBOL )
 {
-plcol0( symbol_colors[i] );
-plssym( 0., symbol_scales[i] );
-dxs = ( plot_x_end_world - plot_x_world - symbol_width ) / (double) ( MAX( symbol_numbers[i], 2 ) - 1 );
-for ( j = 0; j  symbol_numbers[i]; j++ )
+plcol0( symbol_colors[symbol_index] );
+plssym( 0., symbol_scales[symbol_index] );
+dxs = ( plot_x_end_world - plot_x_world - symbol_width ) / (double) ( MAX( symbol_numbers[symbol_index], 2 ) - 1 );
+for ( j = 0; j  symbol_numbers[symbol_index]; j++ )
 {
 xs[j] = plot_x_world + 0.5 * symbol_width + dxs * (double) j;
 ys[j] = ty;
 }
-

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

2010-09-29 Thread Alan W. Irwin
Hi Hez:

On 2010-09-29 21:40-0400 Hezekiah M. Carty wrote:

 On Tue, Sep 28, 2010 at 6:46 PM, Alan W. Irwin
 ir...@beluga.phys.uvic.ca wrote:
 On 2010-09-28 14:30-0700 Alan W. Irwin wrote:

 For the simplest is best reasons [...], I am going to drop cmap1
 from pllegend.  I will try to finish that by late this afternoon.

 Done as of revision 11231.


 While working on the OCaml interface to pllegend, I came up with a
 potential improvement to the C interface:

 What do you think of changing the pllegend API somewhat to allow only
 specifying the entries which are actually used?  For example, if there
 are no symbols, the symbol arrays would be empty.  If there are two
 lines and one box, there would be two elements in the line arrays and
 one in the box array.  nlegend would still be the total number of
 entries in the legend, and opt_array would be used to specify where
 the legend entries are placed.

 Here is a example subset of parameters:

 nlegend: 4
 opt_array: PL_LEGEND_LINE, PL_LEGEND_LINE, PL_LEGEND_SYMBOL |
 PL_LEGEND_LINE, PL_LEGEND_LINE
 line_colors: red, blue, purple, green
 symbol_colors: blue, yellow

 From these (plus styles, widths, symbols, etc), the legend would show up as:

 1. blue symbols, red line
 2. blue line
 3. yellow symbols, purple line
 4. green line

 Does this make sense?  I think it would make passing arguments to
 pllegend a bit more predictable as no dummy entries are required, but
 I don't know if others would feel the same way.

 I'm willing to make an attempt at implementation if you think it is
 worth considering.

Thanks for thinking some more about what is possible with pllegend,
but in this case I do not like this idea.  Instead, I prefer the
present identical dimensions for all quantities so that the same
position of each array always refers to the same legend entry.  I
think that is much less confusing to users (see below for an example).

Furthermore, note I have been careful with the present implementation
to insure no unused quantities (as determined by the bits set in each
entry for opt_array) are ever referred to.  So you only have to
specify quantities that opt_array indicates will actually be used.  I
did specify all pllegend arrays completely for example 4 because I
wanted to facilitate my experimentation testing (and hopefully yours
as well) of that example legend with all combinations of possible
opt_array values, but full specification is not necessary, and once we
get to propagating example 4 post-release I will leave opt_array in
its present form, set the unused box arrays for that example to NULL,
and also simply ignore any unused quantities for each legend entry
rather than setting them.  So the preparation and call will look like
this:

 // Draw a legend
 // First legend entry.
 opt_array[0]  = PL_LEGEND_LINE;
 text_colors[0]= 2;
 text[0]   = Amplitude;
 line_colors[0]= 2;
 line_styles[0]= 1;
 line_widths[0]= 1;
 // note from the above opt_array the first symbol (and box) indices
 // do not have to be specified

 // Second legend entry.
 opt_array[1]  = PL_LEGEND_LINE | PL_LEGEND_SYMBOL;
 text_colors[1]= 3;
 text[1]   = Phase shift;
 line_colors[1]= 3;
 line_styles[1]= 1;
 line_widths[1]= 1;
 symbol_colors[1]  = 3;
 symbol_scales[1]  = 1.;
 symbol_numbers[1] = 4;
 symbols[1]= 3;
 // from the above opt_arrays we can completely ignore everything
 // to do with boxes.

 plscol0a( 15, 32, 32, 32, 0.90 );
 pllegend( PL_LEGEND_BACKGROUND, 0.57, 0.85, 0.06, 15,
 nlegend, opt_array,
 1.0, 1.0, 2.0,
 1., text_colors, text,
 NULL, NULL, NULL,
 line_colors, line_styles, line_widths,
 symbol_colors, symbol_scales, symbol_numbers, symbols );

Note the second entry above is especially complicated because two
plotted possibilities are specified for that entry, but a more normal
case would be only one plotted possibility (a box, line, or line of
symbols) alone for each entry which reduces what has to be specified.

I am also thinking about the possibility of specifying defaults for
many/most arrays that are set to NULL within pllegend for the core C
library.  For example, if line_styles (or box_patterns) is NULL use a
continuous line (or solid fill for the box) for each entry, But this
change concerning the meaning of a NULL array in the core C version
doesn't change the core C version API so I intend to think some more
about this after the release before doing anything about it.

Also, for the many of our language bindings that allow function
overloading, I think as a convenience to users it would be fine to
have 7 overloaded pllegend possibilities corresponding to the 7
possibilities (assuming you are going to exclude the not, not, not
combination) of boxes or not; lines or not; and symbols or not.  Also,
there may well be additional overloading 

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

2010-09-29 Thread Alan W. Irwin
 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.

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


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

2010-09-28 Thread Hezekiah M. Carty
On Sun, Sep 26, 2010 at 12:50 AM, Alan W. Irwin
ir...@beluga.phys.uvic.ca 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

--
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


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

2010-09-28 Thread Alan W. Irwin
On 2010-09-28 08:43-0400 Hezekiah M. Carty wrote:

 On Sun, Sep 26, 2010 at 12:50 AM, Alan W. Irwin
 ir...@beluga.phys.uvic.ca 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 

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

2010-09-28 Thread Hezekiah M. Carty
On Tue, Sep 28, 2010 at 2:03 PM, Alan W. Irwin
ir...@beluga.phys.uvic.ca wrote:
 On 2010-09-28 08:43-0400 Hezekiah M. Carty wrote:
 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.


This sounds reasonable to me.  It would be nice to be able to mix and
match cmap0 and cmap1 in the same legend - could this be done with a
per-entry flag?  In this case, each entry's color would be interpreted
according to the matching flag.  A possible exception would be the
text color for legend entries - it would probably be a good idea to
leave them as cmap0 (PLINT) only.

 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).


The simplest option I see is to make all of the color arguments PLFLT.
 This would require a user of the C API to copy their cmap0 PLINT
array to a PLFLT array, but it limits the number of arguments.

Making the arguments void * could be used here, but it makes the API
more fragile.  There is nothing to stop a user from passing in the
wrong kind of array and getting a segfault at runtime, or worse, no
segfault and silently produced bad output.

 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?


This would likely make language bindings more difficult, but not
terribly so in the case of OCaml - the pllegend function already needs
to be wrapped by hand.  I can't speak for other 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.


Sticking with cmap0 as the only option is certainly the simplest
approach.  I do think cmap1 is worth supporting, but it's probably
worth polling the rest of the PLplot developers to see what others
would prefer.

I can likely provide more feedback and assistance later this evening,
but I hope these initial thoughts are helpful.

Hez

--
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


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

2010-09-28 Thread Alan W. Irwin
On 2010-09-28 16:24-0400 Hezekiah M. Carty wrote:

 On Tue, Sep 28, 2010 at 2:03 PM, Alan W. Irwin
 ir...@beluga.phys.uvic.ca wrote:
 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.


 This sounds reasonable to me.  It would be nice to be able to mix and
 match cmap0 and cmap1 in the same legend - could this be done with a
 per-entry flag?
 In this case, each entry's color would be interpreted
 according to the matching flag.  A possible exception would be the
 text color for legend entries - it would probably be a good idea to
 leave them as cmap0 (PLINT) only.

After thinking about this some more I have changed my mind, and I now
feel strongly that simplest is best so we should just use cmap0 colors
for all the various kinds of colors. After all, this is just a
discrete legend API so it would be natural to use discrete colors with
it.  As soon as you add the choice of cmap1 colors for the extreme
minority of our users that use them in discrete situations, then the
API possibilities start to proliferate like mad with extra arguments
required to determine separate cmap0 or cmap1 choices for bg_color,
text_colors, line_colors, symbol_colors, and block_colors.  To make
things worse, the latter four of those are per entry. In sum, I just
don't think all those API complications are worth it in order to
support what I feel is always going to be an extreme minority use
case.


 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).


 The simplest option I see is to make all of the color arguments PLFLT.
 This would require a user of the C API to copy their cmap0 PLINT
 array to a PLFLT array, but it limits the number of arguments.

I guess that is the best option if we are going to deal with cmap1 at
all, but the downside is it will confuse users to have two
interpretations of their floating point numbers depending on a
proliferation of cmap0/cmap1 choice options in the API. Thus, as I
said above, I now want to keep this simple and stick with cmap0 alone.

 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.


 Sticking with cmap0 as the only option is certainly the simplest
 approach.

For the simplest is best reasons above, I am going to drop cmap1
from pllegend.  I will try to finish that by late this afternoon.


 I can likely provide more feedback and assistance later this evening,
 but I hope these initial thoughts are helpful.

Very much so.  They brought to my attention some of the complications
inherent to catering to cmap1 usage in discrete color situations so I
think we are going to have a simpler and therefore better pllegend API
as a result.

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

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

2010-09-28 Thread Hezekiah M. Carty
On Tue, Sep 28, 2010 at 5:30 PM, Alan W. Irwin
ir...@beluga.phys.uvic.ca wrote:
 On 2010-09-28 16:24-0400 Hezekiah M. Carty wrote:
 Sticking with cmap0 as the only option is certainly the simplest
 approach.

 For the simplest is best reasons above, I am going to drop cmap1
 from pllegend.  I will try to finish that by late this afternoon.


That sounds perfectly reasonable to me.  The plcolorbar API will need
cmap1 support, but that is/will be useful with a different kind of
plot.

Hez

--
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


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

2010-09-28 Thread Alan W. Irwin
On 2010-09-28 14:30-0700 Alan W. Irwin wrote:

 For the simplest is best reasons [...], I am going to drop cmap1
 from pllegend.  I will try to finish that by late this afternoon.

Done as of revision 11231.

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


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

2010-09-25 Thread Alan W. Irwin
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 

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

2010-09-25 Thread Alan W. Irwin
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
__

--
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


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

2010-09-25 Thread Alan W. Irwin
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
__

--
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


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

2010-09-18 Thread Hezekiah M. Carty
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:


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

2010-09-15 Thread Alan W. Irwin
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
__

--
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


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

2010-09-14 Thread Arjen Markus
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.





--
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


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

2010-09-14 Thread Alan W. Irwin
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
__

--
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


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

2010-09-14 Thread Alan W. Irwin
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
__

--
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


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

2010-09-11 Thread Alan W. Irwin
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 

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

2010-09-10 Thread Hezekiah M. Carty
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.

Revision 11166 adds pllegend.c, and will hopefully build successfully.

Hez

--
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