Sun 18 Sep 2016 04:51:12 PM UTC, comment #6:
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:
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)
|