[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #49243] printing causes error when figure axes
[Octave-bug-tracker] [bug #49243] printing causes error when figure axes has color "none"
Sun, 2 Oct 2016 17:14:15 +0000 (UTC)
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0
Follow-up Comment #4, bug #49243 (project octave):
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
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.
Reply to this item at:
Message sent via/by Savannah