Wed 22 Feb 2012 04:22:06 PM UTC, comment #27:
Drat. Thanks for that spelling correction.
|
Wed 22 Feb 2012 01:16:25 PM UTC, comment #26:
I'm surprised I didn't catch the typo when I tested Rik's change. I must have done something wrong when updating.
In any event, I've pushed a fix.
http://hg.savannah.gnu.org/hgweb/octave/rev/1928af0f641b
|
Wed 22 Feb 2012 04:39:37 AM UTC, comment #25:
note that the initial example still does not work:
%> octave -q --no-init-file foo.m
error: `v' undefined near line 154 column 15
error: evaluating argument list element number 1
error: called from:
error: /tmp/octave-3.7/share/octave/3.7.0+/m/plot/private/__fltk_print__.m at line 154, column 3
error: /tmp/octave-3.7/share/octave/3.7.0+/m/plot/print.m at line 395, column 12
error: /tmp/foo.m at line 5, column 1
|
Tue 21 Feb 2012 10:05:16 PM UTC, comment #24:
I pushed a changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/6b2448555bbd). Closing this report.
|
Tue 21 Feb 2012 07:26:26 PM UTC, comment #23:
Opps !
The "visible", "on" should be removed (it's on inherited by the children).
The corrected version is below.
|
Tue 21 Feb 2012 07:12:53 PM UTC, comment #22:
The GL2PS_BSP_SORT has less trouble with 2D plots than GL2PS_NO_SORT has with 3D. Perhaps the subplot problem can be mitigated by checking that all plots are 2D before switching to GL2PS_NO_SORT ?
Using this changeset, I don't see any problems with any of the plot demos. If we add a subplot demo that includes a 3d mesh and a 2d filled contour, then I expect the 2d filled contour to have problems.
Unless you see a way to use different viewports for different axes, I suggest you push the changeset.
|
Tue 21 Feb 2012 06:05:36 PM UTC, comment #21:
I've made a stab at coding something which switches the gl2ps sort order based on whether the plot is 2D or 3D. It is definitely not final but I want to see what you think.
I fear it will break for subplots where one axis might be 2D and another 3D. I didn't see a quick way to handle that yet.
(file #25101)
|
Tue 21 Feb 2012 04:47:28 PM UTC, comment #20:
After looking over the gl2ps docs, my understanding is that a single output stream can have multiple viewports ... Each with independent sorting (one can use GL2PS_BSP_SORT, and another GL2PS_NO_SORT) ?
If so, can gl2ps-renderer.cc/h be rewritten so that each axes has its own viewport.
This would allow 2D axes (where the axes property view(2) == +/- 90) to use GL2PS_NO_SORT, and 3D axes to use GL2PS_BSP_SORT.
|
Tue 21 Feb 2012 02:35:08 AM UTC, comment #19:
After running four sets of demos, the GL2PS_NO_SORT variety produces perfect 2D plots and 3D plots with no hidden line removal.
The GL2PS_BSP_SORT variety produces flawless 3D plots, but doesn't get the order of 2D object correct. The 1st contourf demo is a good example.
The GL2PS_SIMPLE_SORT is only marginally better for 2D plots as compared to GL2PS_BSP_SORT, but still has many problems with ordering of objects.
Changing the zlim property in print.m fixed the problem that initiated this bug report, but other 2D plots still suffer (contourf for example).
Perhaps the gl2ps code needs a patch to avoid changing the sort order of objects with the same depth from the viewer?
|
Tue 21 Feb 2012 02:14:43 AM UTC, comment #18:
I forgot to mention that using GL2PS_SIMPLE_SORT instead of GL2PS_BSP_SORT fixed a lot of problems I see with 2D gl2ps output on MacOS X.
I'm running all the plot demos and saving the results.
I can attach plots for those who are interested.
|
Tue 21 Feb 2012 01:42:06 AM UTC, comment #17:
Rik,
I took a look at gl2ps_renderer.cc. The GL2PS_XXX_SORT is passed as part of gl2psBeginPage (). This is a problem because the choice between GL2PS_BSP_SORT and GL2PS_SIMPLE_SORT needs to be axes specific.
Does this imply that the changeset for pint.m is the proper approach?
|
Mon 20 Feb 2012 09:23:49 PM UTC, comment #16:
Rik, I think either of those solutions will fix the problem.
The only caveat is that it breaks hidden line removal. Take a look at printed output for any the demos for cylinder, ellipsoid, ezmesh, ezsurf, pie3, quiver3, shading, surf, surfc, or trisurf.
It should be sufficient to use GL2PS_BSP_SORT if (abs (view(2)) != 90) and use GL2PS_SIMPLE_SORT or GL2PS_NO_SORT otherwise.
|
Mon 20 Feb 2012 08:17:46 PM UTC, comment #15:
Interestingly, if I switch to GL2PS_NO_SORT it also clears up other Z-stacking related bugs like this one (https://savannah.gnu.org/bugs/?32206) where the colorbar does not appear on top when printing.
|
Mon 20 Feb 2012 07:54:03 PM UTC, comment #14:
The patch is very close. It works for objects which are put on the plot, like lines, but the tickmarks on the axes are still obscured because they are at the same Z level as the axis background.
What about changing the object sort ordering used by gl2ps? From the documentation at http://geuz.org/gl2ps/ I see the following for the sort order:
Currently Octave is using GL2PS_BSP_SORT. However, when I set the sort order to GL2PS_NO_SORT, which is for 2-D plots, then everything works correctly. I've attached a simple diff to show what I mean.
If we went this way we could code a test to check for 2D plots and give the correct options to gl2psBeginPage ().
(file #25094)
|
Mon 20 Feb 2012 04:41:02 PM UTC, comment #13:
I forgot to restore the zlimmode. Second changeset is attached.
(file #25089)
|
Mon 20 Feb 2012 02:53:12 PM UTC, comment #12:
Now with the changeset attached !
(file #25087)
|
Mon 20 Feb 2012 02:51:43 PM UTC, comment #11:
I think the problem manifests in opengl_renderer::draw_axes_planes in gl-render.cc
For 2D plots, the zlim can be shifted to place the zplane at a location that is further away from the viewer.
I've attached a changset.
|
Mon 20 Feb 2012 01:12:51 PM UTC, comment #10:
saveas() worked like print() did.
I have a faint recollection that I had modified the print() function to behave as Matlab does a few years back. If so this choice was revisited more recently.
We're likely to get complaints either way, but I'm inclined to favor Matlab compatibility ... just because I know how to fix that ;-)
|
Mon 20 Feb 2012 04:07:39 AM UTC, comment #9:
This seems bogus to me. What if the image being produced is for a screen rather than a printer? And there are many color printers available so a color background would be quite feasible.
Maybe Matlab only does this for print? What about the same commands but with saveas?
|
Mon 20 Feb 2012 03:32:42 AM UTC, comment #8:
Rik,
Both the axes and the figure backgrounds are white (or "none")
|
Mon 20 Feb 2012 03:11:03 AM UTC, comment #7:
I found a whole thread about the background plot color issue here (http://octave.1599824.n4.nabble.com/color-quot-none-quot-for-figures-td1653194.html).
Ben, you had already noted that Matlab apparently messes with the background color property when printing. I'm wondering what Matlab does for the following.
Does this produces a blue square enclosing a magenta square? Or does it clear the figure color and produce only a magenta square on a white background?
|
Sun 19 Feb 2012 11:35:11 PM UTC, comment #6:
As a temporary fix, we could set the color of the axes to "none" during the print process.
I assume the current fltk implementation draws a rectangle with color [1 1 1]. Is there a way to tell OpenGL the background at an infinite distance is colored instead ?
|
Sun 19 Feb 2012 10:48:49 PM UTC, comment #5:
But in my original example there is no difference between line and plot (the latter with 'hold on').
That is, even when using 'plot' I don't see the line and ticks in the figure. I do see them in Ben's example.
|
Sun 19 Feb 2012 09:01:10 PM UTC, comment #4:
I took your suggestion and compared the differences between plot() and line() which did immediately reveal the problem. The issue is that when using line() the background color of the plot is set to [1 1 1] or all white. When using plot() the color is 'none' or transparent.
This doesn't seem to be a problem with the OpenGL renderer for the screen because the Z-order stacking is correct, i.e., the stacking is background at bottom, axis ticks on top of that, lines and any other objects at top of stack.
When printing, however, the background of the plot is placed on top of most of the other objects and hides the the tick marks and any line objects.
Sample code:
|
Sat 18 Feb 2012 11:46:22 PM UTC, comment #3:
What surprises me is that if line() is replaced by plot(), then then the output is correct.
Either way, it does look like a gl2ps bug. Perhaps isolating the difference in the object properties resulting from line() and plot() can help isolate the bug.
|
Sat 18 Feb 2012 10:17:08 PM UTC, comment #2:
The problem may lie in gl2ps.c. I used the following to get the raw PostScript output
This prints things to the screen as well but you can ignore that. Using a PostScript viewer shows that the output is already incorrect at this stage.
|
Fri 17 Feb 2012 11:40:03 PM UTC, comment #1:
I see the line in the plot you attached. However, I don't see the line in the plot foo.png produced when I run the script you provided.
In both cases, the tick marks are missing.
I have no idea what is wrong here. I was suspicious that the changeset below caused the problem, but I checked a prior build and encountered the same problem.
http://hg.savannah.gnu.org/hgweb/octave/rev/81183cd6eaae
I tried the modified script below
It behaves the same as Mhuali's.
If the function is changed to plot (func=@plot), then everything behaves as expected.
This suggests the problem is with _line_.m and might be discovered by comparing to _plt_.m
|
Fri 17 Feb 2012 07:55:40 PM UTC, original submission:
From this
I get the attached figure. Obviously the line and the ticks are missing.
|