Wed 27 Oct 2010 11:57:10 PM UTC, comment #3:
The issue wasn't quite what I thought it was, and perhaps the fltk backend isn't to blame. I believe the correct fix for this is the changeset I pushed in
http://hg.savannah.gnu.org/hgweb/octave/rev/131d56b6d9a3
With this change, both
patch ([0.1, 0.1, 0.9, 0.9, 0.1], [0.1, 0.9, 0.9, 0.1, 0.1], "facecolor", "none", "edgecolor", "flat", "linewidth", 10, "cdata", 20);
and
bar(rand(2,3))
work correctly with the fltk backend..
D.
|
Wed 27 Oct 2010 09:44:56 PM UTC, comment #2:
While looking at the slow contour bug report I figured out why this is happening. The fltk backend is misinterpreting the sense of the facevertexcdata property. It is using the facevertexcdata property to set the edge color, whereas
http://www.mathworks.com/help/techdoc/ref/patch_props.html
states clearly that this affects the facecolor. The _patch_ fucntion in octave sets this value accordingly, and often to [] which results in the fltk backend plotting black edges for the patches. The fltk backend should use the "edgecolor" property instead to set the color of the patch edge.
As I'm working on this stuff now, I'll fix this issue.
D.
|
Wed 22 Sep 2010 08:30:28 AM UTC, original submission:
I noticed that contour lines are not appearing in color with the fltk backend while they do appear in color with the gnuplot backend. I think I've tracked it down to a problem with the patch function. For example:
patch ([0.1, 0.1, 0.9, 0.9, 0.1], [0.1, 0.9, 0.9, 0.1, 0.1], "facecolor", "none", "edgecolor", "flat", "linewidth", 10, "cdata", 20);
gives a blue box with the gnuplot backend but a black box with the fltk backend. I made the linewidth large simply to make it easier to distinguish the color of the line.
|