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