bugGNU Octave - Bugs: bug #44765, Legend object printed below lines...

 
 

bug #44765: Legend object printed below lines in plot

Submitted by:  Guillaume <gyom>
Submitted on:  Tue 07 Apr 2015 05:59:44 PM UTC  
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Guillaume Open/Closed:  Closed
Release:  dev Operating System:  GNU/Linux

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Fri 16 Oct 2015 06:40:51 AM UTC, comment #34: 

I was told that it worked on Windows so I'll close this one too.

Pantxo Diribarne <pantxo>
Project Member
Mon 12 Oct 2015 09:23:35 PM UTC, comment #33: 

I fixed a regression in svg output.

http://hg.savannah.gnu.org/hgweb/octave/rev/395140e53656

We now call gl2psBegin(End)Viewport exactly as in gl2ps examples:

BeginPage
  BeginViewport
    draw_axes
  EndViewport
  BeginViewport
      ...
  EndViewport
EndPage

This structure makes gl2psEndPage return a GL2PS_NO_FEEDBACK warning inevitably (checked in gl2ps examples) and that's why I used to think the last viewport should be ended using gl2psEndPage.

Pantxo Diribarne <pantxo>
Project Member
Sun 11 Oct 2015 07:41:58 PM UTC, comment #32: 

I pushed the patch here:
http://hg.savannah.gnu.org/hgweb/octave/rev/d30fc2c11455

I'll leave this report open until we know what happens on Windows (bug #44806).

Pantxo Diribarne <pantxo>
Project Member
Sun 11 Oct 2015 11:15:36 AM UTC, comment #31: 

Hi,

Back to this annoying bug. I attached a patch which works for me and doesn't break "-dpdflatexstandalone" format.
BTW for the latter format we use GL2PS for PDF rendering not eps and conversion to PDF using ghostscript as we do for "-dpdf". I don't know if it is intensional.

I'll ask for a test on Windows 7 machines that trigger bug #44806.

(file #35144)

Pantxo Diribarne <pantxo>
Project Member
Sat 25 Apr 2015 02:53:06 PM UTC, comment #30: 

I am reopening this report as I have backed out part of the fix (http://hg.savannah.gnu.org/hgweb/octave/rev/1784bf79ed43): it broke all printing formats on some Win7 machines (see bug #44806) and broke -dpdflatexstandalone format for fltk/linux (still broken in Qt, see bug #44463).

Pantxo Diribarne <pantxo>
Project Member
Thu 09 Apr 2015 08:17:55 PM UTC, comment #29: 

I pushed the patch here:
http://hg.savannah.gnu.org/hgweb/octave/rev/438485f6a479

Closing report.

Pantxo Diribarne <pantxo>
Project Member
Thu 09 Apr 2015 07:29:21 PM UTC, comment #28: 

Cool! In case I wouldn't have shouted it loud enough: Inkscape and its XML editor is a great tool to inspect our figures (even from eps files!).

I will cleanup and push the patch soon.

Pantxo Diribarne <pantxo>
Project Member
Thu 09 Apr 2015 07:03:40 PM UTC, comment #27: 

The second patch works!

Rik <rik5>
Project Administrator
Thu 09 Apr 2015 06:52:17 PM UTC, comment #26: 

@Rik: I noticed that one difference between your figures and mine is that some zero-width polygons are drawn : these are superfluous (in 2D mode ) x and y planes. I don't understand why they are not drawn on my figures. Maybe this is due to some opengl driver odity.

Could you test the attached patch?

(file #33617)

Pantxo Diribarne <pantxo>
Project Member
Thu 09 Apr 2015 07:16:20 AM UTC, comment #25: 

@Rik: The svg you sent in comment #23 are now as I expect: one single group of objects, wrong order without the patch.
For the ps/eps output, I have no idea where to search now. Anyway I agree that without further comprehension the patch should not go into the repo before 4.0.

Pantxo Diribarne <pantxo>
Project Member
Thu 09 Apr 2015 05:05:16 AM UTC, comment #24: 

I applied the patch and then made a tarball which I copied over to an MXE build directory and built an nsis installer.  I copied that executable into a Windows VM and tested and I still get a black legend background.  The MXE build is using ghostscript 9.16.  The OpenGL libraries I assume are coming from the Windows distribution itself. 

Rik <rik5>
Project Administrator
Wed 08 Apr 2015 10:38:11 PM UTC, comment #23: 

I'm uploading svg and eps versions from before your patch (tst_old) and after your patch (tst_new).  The problem persists for me.  I will build a version of Octave with your patch for MXE which has ghostscript 9.15 installed and see if it works there.

(file #33603, file #33604, file #33605, file #33606)

Rik <rik5>
Project Administrator
Wed 08 Apr 2015 09:51:34 PM UTC, comment #22: 

@Rik: also, ps is not a good reference neither as it is the result of a conversion in qhostscript. I have 9.10 for and I see you are using 9.05 from the ps file you attached. The eps output in turn comes straight out of gl2ps (as svg).

Pantxo Diribarne <pantxo>
Project Member
Wed 08 Apr 2015 09:22:02 PM UTC, comment #21: 

@Rik: I am puzzled, my svg and ps files have coherent behavior:

  • without the patch the background of the legend is bellow any line : consequently the legend background is next to the top of the svg tree (this can be checked easily with Inkscape's XML editor). Note also that in Inkcape there is only one group of objects, which you have to ungroup in order to manipulate individual objects.
  • with the patch the legend background is drawn on top of any other object as on screen. A consequence of the patch is that in Inkscape there are two groups of objects: one for the first axes, one for the other.

Are you sure the two svg you provided where not both using the patch? They are not exactly the same but they both contain two groups of objects, one for each axes, which has no reason to happen without the patch.

Pantxo Diribarne <pantxo>
Project Member
Wed 08 Apr 2015 07:56:12 PM UTC, comment #20: 

This is related, somehow, to Z-depth and Octave.  If I use

set (gca, 'layer', 'top');

before printing then the generated Postscript is correct.

Rik <rik5>
Project Administrator
Wed 08 Apr 2015 07:53:36 PM UTC, comment #19: 

The svg appears correct, both with and without your patch.  This may indicate that it won't be a good comparison point because it follows a different path through the internals of gl2ps.  I've attached both anyways.

(file #33600, file #33601)

Rik <rik5>
Project Administrator
Wed 08 Apr 2015 07:32:48 PM UTC, comment #18: 

@Rik: Does the svg output also have this black legend ? If so can you attach the svg output ?

Pantxo Diribarne <pantxo>
Project Member
Wed 08 Apr 2015 06:17:48 PM UTC, comment #17: 

Installing a locally built copy of gl2ps 1.3.8 didn't help.

Rik <rik5>
Project Administrator
Wed 08 Apr 2015 05:40:17 PM UTC, comment #16: 

I guess pushing the patch depends on whether I have an unusual machine or not.  If I do, I can work around it by setting the legend color to 'none' and just living with transparency in the output.  In any case, it seems like maybe this shouldn't go in right before the 4.0 release unless more testing can determine why it works some places and not others.

Rik <rik5>
Project Administrator
Wed 08 Apr 2015 05:02:32 PM UTC, comment #15: 

I can't see any mention of such an improvement between 1.3.6 and 1.3.8 in gl2ps announce archive [1]

[1] http://www.geuz.org/pipermail/gl2ps-announce/2012/thread.html

Pantxo Diribarne <pantxo>
Project Member
Wed 08 Apr 2015 04:46:05 PM UTC, comment #14: 

In case this matters, the version of gl2ps I use is 1.3.8.

Guillaume <gyom>
Wed 08 Apr 2015 04:20:15 PM UTC, comment #13: 

I can confirm that on my system the black box is there whether I use FLTK or Qt.  It might be related to my gl2ps version which is 1.3.6.

Rik <rik5>
Project Administrator
Wed 08 Apr 2015 01:11:41 PM UTC, comment #12: 

@Michael: sorry, when writing comment #5 and  #6 I hadn't read your previous posts (the report page was open but not updated). I would have saved time and noise :-).

Pantxo Diribarne <pantxo>
Project Member
Wed 08 Apr 2015 11:32:23 AM UTC, comment #11: 

It seems to work fine after applying Pantxo's patch - I don't observe any black legend background.

Guillaume <gyom>
Wed 08 Apr 2015 07:49:02 AM UTC, comment #10: 

@Rik: can you also try to print using fltk to ensure that the black legend background is not a side effect of using Qt toolkit?

Pantxo Diribarne <pantxo>
Project Member
Wed 08 Apr 2015 06:40:15 AM UTC, comment #9: 

Indeed the image you provided in comment #8 has a black legend but I can't reproduce it with your script.

I attached the image I obtain with your script  and changed the name to white_lg.ps. The output looks good to me.

(file #33588)

Pantxo Diribarne <pantxo>
Project Member
Wed 08 Apr 2015 12:42:19 AM UTC, comment #8: 

The patch works fine when the axes object has a color besides white, or is transparent.  When the legend is white, which is the default, it shows up in the output as a black square.

Sample code:

plot (randn (10));
hl = legend ({'Item 1','Item 2','Item 3','Item 4'}, 'location','east');
print -dpsc2 tst.ps

See also attached tst.ps file.

(file #33587)

Rik <rik5>
Project Administrator
Tue 07 Apr 2015 09:29:01 PM UTC, comment #7: 

The attached patch fixes the issue for me.

(file #33585)

Pantxo Diribarne <pantxo>
Project Member
Tue 07 Apr 2015 08:52:22 PM UTC, comment #6: 

Got it. Before drawing any axes, Octave clears the GL_DEPTH_BUFFER (see opengl_renderer::setup_opengl_transformation), so that subsequent objects are drawn over previous ones. Commenting out this line makes on-screen rendering look like the ps file.

In gl2ps a similar effect could be achieved using gl2psBeginViewport/gl2psEndViewport to init a new sorting tree each time we clear the depth buffer.

Pantxo Diribarne <pantxo>
Project Member
Tue 07 Apr 2015 08:27:58 PM UTC, comment #5: 

FWIW, I could check that this bug is not solved by the recent changes in gl2ps dev that affect the handling of glPolygonOffset.
Actually, as lines are not supposed to be affected by  glPolygonOffset, it is expected that the background of the legend (which is pushed backward using glPolygonOffset) is drawn below the main axes lines.
What I don't understand is how Octave manages to handle this perfectly on-screen :-)

Pantxo Diribarne <pantxo>
Project Member
Tue 07 Apr 2015 07:04:54 PM UTC, comment #4: 

The layer property only modifies where the tick and grid lines are drawn: in the top or the bottom plane of the axes box. This property only makes sense in 2D.

Michael Goffioul <goffioul>
Tue 07 Apr 2015 07:01:03 PM UTC, comment #3: 

For the record, the way it works when drawing on screen is as follows: when drawing a figure, the OpenGL renderer iterates over the children objects, which are mainly(only) axes objects. For each axes object, the code resets the transformation and clears the depth bit in the OpenGL buffer. This means that all axes objects are drawn independently, without considering their relative Z-depth; they are painted in sequence, one on top of each other.

The legend axes is painted after the normal axes, so it will always appear on top of the normal axes object (even if its transformation matrix put it theoretically behind the normal axes object).

It seems that this process is not occurring with using GL2PS and that it will still consider the relative Z-depth of the axes when sorting the primitives.

Michael Goffioul <goffioul>
Tue 07 Apr 2015 06:51:25 PM UTC, comment #2: 

Actually, it may not be transparent but at the bottom, depth-wise.  Add some color:

F=figure;
plot(randn(10));
h = legend({'Item 1','Item 2','Item 3','Item 4'},'location','east');
set(h, 'color', [1 0 0]);
print(F,'figure.ps','-dpsc');

Changing to top layer has no affect, although I'm not sure if that property is for controlling depth.

set(h, 'layer', 'top');
print(F,'figure.ps','-dpsc');

Dan Sebald <sebald>
Tue 07 Apr 2015 06:38:47 PM UTC, comment #1: 

I think the problem is actually slightly different.  It appears that the legend containter is actually printed, but it is below the lines in the Z-depth ordering.

plot (randn (10));
hl = legend ({'Item 1','Item 2','Item 3','Item 4'}, 'location','east');
set (hl, 'color', 'm')
print -dpsc2 tstleg.ps

Check tstleg.ps and you will see the really ugly magenta box of the legend background is shown.

(file #33584)

Rik <rik5>
Project Administrator
Tue 07 Apr 2015 05:59:44 PM UTC, original submission:  

When printing a figure, the background of a legend (initially white) becomes transparent.

F=figure;
plot(randn(10));
legend({'Item 1','Item 2','Item 3','Item 4'},'location','east');
print(F,'figure.ps','-dpsc');

Guillaume <gyom>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #35144:  multi_axes.patch added by pantxo (2KiB - application/x-download)
file #33617:  fix_viewpoint2.patch added by pantxo (2KiB - application/x-download)
file #33603:  tst_old.svg added by rik5 (10KiB - image/svg+xml)
file #33604:  tst_new.svg added by rik5 (10KiB - image/svg+xml)
file #33605:  tst_old.eps added by rik5 (9KiB - application/postscript)
file #33606:  tst_new.eps added by rik5 (9KiB - application/postscript)
file #33600:  leg_print_no_patch.svg added by rik5 (10KiB - image/svg+xml)
file #33601:  leg_print_patch.svg added by rik5 (10KiB - image/svg+xml)
file #33588:  white_lg.ps added by pantxo (91KiB - application/postscript)
file #33587:  tst.ps added by rik5 (91KiB - application/postscript)
file #33585:  fix_viewpoint.patch added by pantxo (1KiB - application/x-download)
file #33584:  tstleg.ps added by rik5 (91KiB - application/postscript)

 

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

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 25 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-07-21 mtmiller Dependencies- => bugs #48581 is dependent
    2016-05-13 mtmiller Dependencies- => bugs #47907 is dependent
    2015-10-16 pantxo StatusNone => Fixed
        Open/ClosedOpen => Closed
    2015-10-11 pantxo Attached File- => Added multi_axes.patch, #35144
    2015-04-25 pantxo StatusFixed => None
        Open/ClosedClosed => Open
        Dependencies- => Depends on bugs #44806
    2015-04-09 pantxo StatusConfirmed => Fixed
        Open/ClosedOpen => Closed
    2015-04-09 pantxo Attached File- => Added fix_viewpoint2.patch, #33617
    2015-04-08 rik5 Attached File- => Added tst_old.svg, #33603
        Attached File- => Added tst_new.svg, #33604
        Attached File- => Added tst_old.eps, #33605
        Attached File- => Added tst_new.eps, #33606
    2015-04-08 rik5 Attached File- => Added leg_print_no_patch.svg, #33600
        Attached File- => Added leg_print_patch.svg, #33601
    2015-04-08 pantxo Attached File- => Added white_lg.ps, #33588
    2015-04-08 rik5 Attached File- => Added tst.ps, #33587
    2015-04-07 pantxo Attached File- => Added fix_viewpoint.patch, #33585
    2015-04-07 pantxo CategoryPlotting => Plotting with OpenGL
        StatusNone => Confirmed
    2015-04-07 rik5 SummaryLegend object printed below => Legend object printed below lines in plot
    2015-04-07 rik5 Attached File- => Added tstleg.ps, #33584
        SummaryTransparent background of legend when printed => Legend object printed below

    Back to the top


    Powered by Savane 3.5