[Octave-bug-tracker] [bug #49108] gnuplot: demo ezmeshc draws contour plot in only one color

[Dan Sebald]

Follow-up Comment #6, bug #49108 (project octave):

OK, I missed the patch edgecolor case.  This meshc example is one of those
hggroup configurations that uses patches.  (As a side note, I notice in the
side-by-side comparison HTML page that the contour level spacing isn't
consistent with Matlab.)

Attached is a fix for the ezmeshc example, but I'm not sure if everything is
covered still as far as color processing.  There remains some patch-sub-marker
cases in __gnuplot_draw_axes__.m that have some color-related code.  I'm
reluctant to change too much just before a release, but this color processing
is getting very repetitive, and there are redundant tests like:


          ## patch outline
          if (!(strcmp (obj.edgecolor, "none")
                 && (strcmp (obj.marker, "none")
                     || (strcmp (obj.markeredgecolor, "none")
                         && strcmp (obj.markerfacecolor, "none")))))
[snip]
            if (isfield (obj, "edgecolor"))


I.e., the code already uses edgecolor, so Octave interpretation would have
failed by time of the "isfield" test.  Also, there are several tests that
check whether the color data has three elements.  Now, I'm guessing that is
meant to test that color data is an RGB triad, but it should really be
direction-specific because it seems to me there could be some case where there
are three elements in some graphics object.  That is,

RGB:
[0.23  0.74  0.48]

Three elements (e.g., triangle):
[0.23
0.74
0.48]

Then again, could there be a fourth entry for alpha channel?  Maybe the test
should be that color data has only one row.

It feels to me that this color processing should be overhauled.  The change I
made with scaled data using the palette index simplified things but there
could be more simplification.  Maybe create a color processing subfunction, or
perhaps move the color processing to after all the graphics object color data
setup.  If anyone has an idea of conceptually where best color can be
processed, please make a suggestion.  We'll aim for post 4.2 to simplify
things.

(file #38542)
    _______________________________________________________

Additional Item Attachment:

File name: octave-gnuplot_patch_edgecolor_bug49108-djs2016sep18.patch Size:2
KB


    _______________________________________________________

Reply to this item at:

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

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