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
