Re: [Plplot-devel] Volunteer requested to implement legend-drawing capability for the PLplot core library.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
