[Octave-bug-tracker] [bug #48667] Colormap not controllable at the axes level

[Dan Sebald]

Follow-up Comment #5, bug #48667 (project octave):

[1] goes on to give an example of separate colormaps.  Odd that's all that is
mentioned for this, isn't it?  [1] is tagged with R2016a, while [2] is 2012. 
Perhaps it is so recent that documentation hasn't caught up.

To me, what would make sense is that axes also have colormap and clim,
climmode, but perhaps have a further option "parent" which means that the info
comes from the parent figure.

In any case, if there is some way of creating an object for the colormap and
simply reuse that code whether the object is an axes or a figure, that would
be nice.  I can change the __gnuplot_draw_axes__.m to look for the colormap
first at the axes level and then at the figure level.

Should hggroup, patch, et al. get a colormap?  I don't know.  The reason is
that multiple colormaps within an axes might just be confusing.  For each
colormap there needs to be the ability to add an associated color box/bar on
the plot.  It's conceivable to do such a thing by say, picking a color tone
for the two different objects and modulating the intensity to correlate
against the colorbox scale.  But at the same time, the user could just create
two different subplots side by side to achieve that.  That is, what
application is going to need both spatial dimensions and color dimension
critical to displaying information?  I'd say, just axes for now, as that one
seems obvious.  And if later some user finds a need for individual elements,
reconsider.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?48667>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/