Sun 02 Oct 2016 05:14:15 PM UTC, comment #4:
Yes, I'm not sure exactly what this "color" refers to, i.e., whether it means the default color or the background color, or both.
It's not the most far-fetched case, as its usefulness would be for someone who wants all the plot elements accept a background. Say, for example, s/he wants a PNG that would overlay some HTML background who's color is not known.
In trying to solve the hidden axes tick labels of https://savannah.gnu.org/bugs/?49223, I thought setting all the colors (backgrounds?) to none, it wouldn't matter what order we have. (Not elegant, but just an alternative solution.) It seems to me though, that print.m is imposing some rules about the background because when I use drawnow() to create an intermediate file there are no rectangles--I run the GP file through gnuplot, then compile with pdflatex, and the tick labels are visible. But if I use print() to generate the LaTeX file directly and run pdflatex, the tick labels are still hidden. So I wonder if print() is assuming some background color. Don't know, it's a bit confusing to manage.
The black background (or any background) of OpenGL would be fine if it changed upon running
set(gcf, 'color', 'none')
set(gca, 'color', 'none')
but it's not until the print() command that this occurs. Perhaps the logic is that there is no need to update if the color is changed to 'none'.
For PostScript devices, such as 'gv', if there is nothing but lines and text (no background rectangles), white is the default. But again, I'm not sure whether "color" property means background.
|
Sun 02 Oct 2016 02:31:50 PM UTC, comment #3:
We could check what Matlab does when both the figure and axes color properties are set to "none". But, this is such an extreme corner case I'm not that worried if we aren't compatible or don't fix it. OpenGl seems to choose a black pixel when there is nothing to display. I guess the other choice would be a white pixel, but I'm not sure why one choice would be better than another.
At least for printing, with "inverthardcopy" set to "off", the figures seem correct with the white of the page showing through.
Test code:
|
Sun 02 Oct 2016 02:38:15 AM UTC, comment #2:
That solves the error, but there might still be some issues here. When I set
set(gcf, 'color', 'none')
set(gca, 'color', 'none')
for gnuplot I see that there is not the usual two filled rectangles in the test.gp gnuplot script file. Though I was expecting the tick annotation to become visible, it still seems to be hidden behind the PostScript graphics.
In the case of Qt and FLTK toolkits, try the following:
and the onscreen plot acquires a black background.
|
Sun 02 Oct 2016 01:46:52 AM UTC, comment #1:
I pushed a fix on the stable branch here (http://hg.savannah.gnu.org/hgweb/octave/rev/956f5c71dc3c).
|
Sat 01 Oct 2016 09:27:40 PM UTC, original submission:
The following illustrates the problem:
The code that is causing the error is this hunk from print.m:
As shown in line octave:70 above, the result of the find all is an empty set because of the "-not","color","none" setting. We should consider if that "color" "none" should in fact exclude printing, but also decide what to do rather than let an error be thrown.
|