bugGNU Octave - Bugs: bug #49243, printing causes error when figure...

 
 

bug #49243: printing causes error when figure axes has color "none"

Submitter:  Dan Sebald <sebald>
Submitted:  Sat 01 Oct 2016 09:27:40 PM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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.

Dan Sebald <sebald>
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:


close all
graphics_toolkit fltk
plot (1:10, "o-b", "linewidth", 5)
set (gca, "linewidth", 5, "xcolor", "r", "ycolor", "g");
set (gca, "color", "none");
set (gcf, "color", "none");
set (gcf, "inverthardcopy", "off");
print -dpsc2 tst.ps



Rik <rik5>
Group administrator
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:


graphics_toolkit fltk
figure(1)
plot([-10:10],[-10:10].^2,'o-')
set(gcf, 'color', 'none')
set(gca, 'color', 'none')
print('-dpdflatexstandalone','-color','test')


and the onscreen plot acquires a black background.


Dan Sebald <sebald>
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).

Rik <rik5>
Group administrator
Sat 01 Oct 2016 09:27:40 PM UTC, original submission:  

The following illustrates the problem:


octave:60> close all
octave:61> graphics_toolkit ('gnuplot')
octave:62> figure(1)
octave:63> plot([-10:10],[-10:10].^2,'o-')octave:64> set(gca, 'color', 'none')octave:65> print('-dpdflatexstandalone','-color','test')
ans =  1
hax = [](0x1)
ans = 0
error: 'n' undefined near line 412 column 15
error: called from
    print at line 412 column 12
octave:65> graphics_toolkit ('fltk')
octave:66> figure(2)
octave:67> plot([-10:10],[-10:10].^2,'o-')
octave:68> set(gca, 'color', 'none')
octave:69> print('-dpdflatexstandalone','-color','test')
ans =  2
hax = [](0x1)
ans = 0
error: 'n' undefined near line 412 column 15
error: called from
    print at line 412 column 12
octave:69>  findall (2, "-depth", 1, "type", "axes", "-not", "tag", "legend")ans = -80.669
octave:70>  findall (2, "-depth", 1, "type", "axes", "-not", "tag", "legend", "-not", "color", "none")
ans = [](0x1)
octave:71>


The code that is causing the error is this hunk from print.m:


    if (do_hardcopy)
      ## Set background to white for all top-level axes objects
      hax = findall (opts.figure, "-depth", 1, "type", "axes",
                                  "-not", "tag", "legend",
                                  "-not", "color", "none");
      m = numel (props);
      for n = 1:numel(hax)
        props(m+n).h = hax(n);
        props(m+n).name = "color";
        props(m+n).value{1} = get(hax(n), "color");
        set (hax(n), "color", "white");
      endfor
      nfig += n;
    endif


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.

Dan Sebald <sebald>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by sebald (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-10-02 rik5 StatusNone Fixed
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code