Wed 30 Apr 2014 06:37:20 PM UTC, comment #18:
It's related. Legend objects are implemented by Matlab, and also Octave, as a second axes object on the figure. This is kind of a weird re-use and the OpenGL drawing code is not set up for it. I'm going to have to think about this for a while to see if there is a clean solution.
|
Wed 30 Apr 2014 11:17:07 AM UTC, comment #17:
I'm not sure the problem is related to your fix but if there's a legend on a chart then its face is being moved to the bottom layer when printed while all the edges are still shown.
Can anyone confirm the result of the following code? Attached file was made with cset 95a1ee1cbdf1.
(file #31285)
|
Tue 29 Apr 2014 06:55:10 PM UTC, comment #16:
I believe I have fixed the Z-order printing problem in this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/abd8d8c686c9). The bug can be re-opened if new examples are found which cause a problem.
|
Wed 16 Apr 2014 12:42:34 AM UTC, comment #15:
Interestingly, this does work if the patch is 3-D, but with all Z=0. I suspect something odd in the difference between 2-D/3-D code with OpenGL itself.
Using your example,
|
Tue 15 Apr 2014 01:59:39 PM UTC, comment #14:
Confirmed. The 'layer' attribute does not seem to have an effect for patches.
It does work with line objects.
Now if you zoom in on a section where the line crosses the minor grid axis you can change which one is on top with
I think the issue is that this behavior has never been coded in gl-render.cc for patch objects.
|
Tue 15 Apr 2014 09:22:07 AM UTC, comment #13:
Actually, on-screen rendering for a simple patch doesn't seem to be working well.
In the example above grid lines appears to be always at the top layer, which doesn't coincide with Matlab, where layer option change affects them.
Can anyone confirm it?
|
Sun 16 Mar 2014 07:57:02 PM UTC, comment #12:
I just re-ran the example in this bug report with a development tip (3a1a4d587c4e) and I still get the problem. At least the on-screen rendering is now fixed, but printing doesn't respect the 'layer' property of the axis. I re-titled the bug report to reflect that.
|
Thu 01 Mar 2012 12:48:14 PM UTC, comment #11:
I'm using fltk 1.1.10 from MacPorts. There have been several cases where fltk on MacOS (aqua) doesn't behave in the same manner as on x11 (for example see the attached figure window I "close all; axis")
(file #25228)
|
Thu 01 Mar 2012 01:09:54 AM UTC, comment #10:
I am using fltk 1.3.0 as comes with
Fedora 16.
|
Wed 29 Feb 2012 11:12:46 PM UTC, comment #9:
What version of FLTK are Ben or Michael using? I have 1.10 and the grid is always under the color squares both on screen and in the printed version. Gnuplot works fine and the 'layer' command works with that backend.
|
Wed 29 Feb 2012 07:02:33 PM UTC, comment #8:
I'm attaching the Octave+Gnuplot results for
Octave's pdf output looks like Matlabs (the eps version does as well). Apparently, we're compatible with Matlab ?
I don't understand how the eps/pdf version are smeared, but the png is not.
(file #25216, file #25217)
|
Wed 29 Feb 2012 06:01:48 PM UTC, comment #7:
It is possible that you've found a bug in Matlab.
One last thing to check, however, is the value of the 'layer' property for the current axis. According to Matlab, 'layer' can be either 'top' or 'bottom'. When it is 'top', the axis is drawn over the line objects and other items at Z-stack = 0. When it is 'bottom' {default} any other objects at Z-stack = 0 are on top of the axis.
I'm attaching a script (mk_bad_plots.m) which demonstrates the problem. gnuplot does the correct thing, incidentally, and if you zoom in to the top of the plot where the sine curve touches the axis you can see which one is on top.
(file #25215)
|
Wed 29 Feb 2012 01:09:26 PM UTC, comment #6:
Matlab give different results for pdf and png.
I looks to me as if the pdf result isn't rendered correctly (a bug?).
Matlab's png looks like Octave's.
I think the grid lines should be visible. Perhaps we should just draw the grid lines last ?
(file #25213, file #25214)
|
Wed 29 Feb 2012 05:20:19 AM UTC, comment #5:
Rik,
Using 3.6.1 on Fedora 16 your example below
shows correct grid lines on screen and in PDF.
|
Wed 29 Feb 2012 04:47:04 AM UTC, comment #4:
I can't confirm the print output because I don't even get a grid with the onscreen version. The following should produce multicolor blocks with lots of grid lines, and it does that with gnuplot but not with FLTK.
I checked the axes properties with 'get (gca)' and all the grid properties are correctly turned on but no lines are drawn.
Actually, I just figured it out. This is a problem with Z-stacking order again. The colored squares from imagesc are drawn above the axis. Therefore, even when the grid is turned on it is hidden. You can see that this is happening by using the example above and
How does Matlab behave for any of these examples?
|
Wed 29 Feb 2012 03:35:24 AM UTC, comment #3:
I can confirm Mulali's example.
Rik, do you see it too?
|
Tue 28 Feb 2012 01:43:52 AM UTC, comment #2:
that may have been too general. Try this:
|
Tue 28 Feb 2012 01:20:21 AM UTC, comment #1:
This works for me with the FLTK backend
This might be something particular about your version of Octave or FLTK.
|
Mon 27 Feb 2012 10:29:34 PM UTC, original submission:
as a follow-up to bug 35559,
for any plot
displays the dotted grid lines in the plot but not in the print.
|