Thu 09 Nov 2017 04:41:41 PM UTC, comment #21:
Closing report. The issue with spurious anti-aliasing lines is a different issue.
|
Wed 08 Nov 2017 10:34:05 PM UTC, comment #20:
AFAICS the original issue is gone (no more missing patches). This probably due to the fact that 2D figures are now drawn and printed without depth sorting.
The vertical lines are a known issue which is tracked in bug #45494.
Can I mark this bug fixed and close the report?
|
Wed 08 Nov 2017 08:42:13 PM UTC, comment #19:
A pic with the results on windows 7 is attached.
Left the .pdf, right Octave's figure window.
The pdf shows some vertical light-colored traces
(file #42351)
|
Wed 08 Nov 2017 10:04:26 AM UTC, comment #18:
Can someone check that this bug is still present with the current dev Octave?
|
Mon 21 Nov 2016 10:46:14 PM UTC, comment #17:
I've simplified the original test case. The new m-file is tst_pdfshading.m, along with the data file shading_data.var.
Within Octave, execute
The resulting output file is out2.pdf and it is clearly very different from the onscreen plotted result. I tested this in a Windows XP virtual machine with Octave-4.2.0 [w32]. On Linux, everything works correctly.
(file #39042, file #39043)
|
Mon 21 Nov 2016 07:38:50 PM UTC, comment #16:
I checked with Octave 4.2.0 (w64) under Windows 8.1. the result is attached and is still not displayed correctly.
files:
out1_20161121.pdf
out2_20161121.pdf
(file #39040, file #39041)
|
Sun 20 Nov 2016 06:28:14 PM UTC, comment #15:
Can the original reporter re-test with the newly release Octave-4.2.0?
|
Mon 29 Feb 2016 09:10:35 AM UTC, comment #14:
I submitted a comment to the other bug report, linking it to this one.
Thank you for your help everyone!
|
Mon 29 Feb 2016 09:02:53 AM UTC, comment #13:
I believe the issue with missing colors in the colorbar has been fixed in default (the future 4.2 release): gl2ps now treats the axes and the colorbar (another axes by the way) in two independent depth trees so this should also be fixed once Octave 4.2 is released.
We don't generally merge bug reports but it may be useful to make a comment in the report of bug #47217 stating that z-level issues can be triggered by contourf and point to this report. Can you do that?
|
Mon 29 Feb 2016 08:41:20 AM UTC, comment #12:
Adding those lines before printing helped for the PDF output. Both PDF plots look fine now.
EPS output (out2.eps) looks fine, too. However, out1.eps is missing a legend on the 'colorbar' and the right part of the contour plot stays blank.
out1.svg and out2.svg are missing the colours in the 'colorbar', while the legend is being shown.
In conclusion, your workaround seems to solve the problems for PDF output only. Thank you very much for pointing this out, though!
Is there a way to merge this bug reports with the one you just mentioned?
(file #36503)
|
Fri 26 Feb 2016 06:07:34 PM UTC, comment #11:
If it is a culling problem in gl2ps then maybe forcing the depth would be a workaround.
Does adding the following before printing change anything?
If so then it may be somewhat related to bug #47217: the order of objects in the children stack is not always respected and should be forced in some way.
|
Fri 26 Feb 2016 07:16:45 AM UTC, comment #10:
So, what kind or problem are we looking at? Is it a bug with Octave or GL2ps or can this issue be solved another way?
Best regards,
Michael
|
Tue 23 Feb 2016 04:58:41 PM UTC, comment #9:
So no doubt octave 4.0.1-rc3 is using the most recent gl2ps.
|
Tue 23 Feb 2016 04:01:49 PM UTC, comment #8:
Here is the svg output from Octave 4.0.0 and the RC 3 version.
The renderer actually changed, but the output is still erroneous.
(file #36439, file #36440, file #36441, file #36442)
|
Tue 23 Feb 2016 10:00:17 AM UTC, comment #7:
@OP: just to make sure the last release candidate for windows makes use of the most recent gl2ps, can you run the following and report back:
If the image is properly saved then this is gl2ps 1.3.9, the fixed version.
Can you also attach the svg output of the original failing example?
|
Tue 23 Feb 2016 07:41:56 AM UTC, comment #6:
@Mike: Thank you for this tip.
Regarding my reported problem with the 'fltk' and 'qt' toolkits: Is there a solution to this or are we looking at a bug?
Best regards,
Michael
|
Sun 21 Feb 2016 07:51:36 PM UTC, comment #5:
You may want to ask your gnuplot-related usage questions on the help mailing list help@octave.org.
|
Sat 20 Feb 2016 09:28:34 AM UTC, comment #4:
Hello again,
I checked the output with octave-4.0.1-rc3. Please note that I used a different computer, running Windows 10/64bit. Even though, I believe the latter does not make a difference. Octave had never been installed on this machine before.
The output ist still subject to the same faulty behaviour. 'gnuplot' yields valid output to pdf, while 'fltk' and 'qt' fail (files attached).
Besides: Is there a way to (automatically) fix the placement of the xlabel and ylabel, when using 'gnuplot'?
Kind regards,
Michael
(file #36408, file #36409, file #36410)
|
Fri 19 Feb 2016 10:10:23 AM UTC, comment #3:
Hi,
I can't reproduce either on linux but this may well be due to a bug in gl2ps which could show differently in different opengl implementations: the current version of octave on windows (and on linux) uses gl2ps 1.3.8 which was affected by a bug that make some patches be hidden behind others. As I believe that the latest mxe-builds for windows uses the latest version of gl2ps (1.3.9), can the OP test octave 4.0.1 release candidate:
http://alpha.gnu.org/gnu/octave/octave-4.0.1-rc3.zip
@Mike:
The diagonal line are a known bug: patches are tesselated into smaller triangles and the lines you see are an artifact of anti-aliasing. I don't think ghostscript is responsible, but rather that the viewer behaves differently with eps and pdf files.
|
Fri 19 Feb 2016 07:56:07 AM UTC, comment #2:
Thank you for your quick response.
I re-created both files with the graphics_toolkit 'gnuplot'. Please check the results below. There are white areas (e.g. top left), whereas the 'qt' and 'fltk'-based files are completely grey in these areas.
Thus, the graphs are not consistent between 'gnuplot' and for example 'qt', especially because the scaling on the colorbar is the same.
(file #36394, file #36395)
|
Thu 18 Feb 2016 07:11:56 PM UTC, comment #1:
I see faint vertical line artifacts in the output, but I don't see wrong colors when comparing against the gnuplot output or against the original eps output file.
Try printing to an eps file and compare against the pdf. I see much fainter vertical line artifacts in that file, it seems that ghostscript is enhancing those artifacts in the pdf conversion.
|
Thu 18 Feb 2016 02:34:17 PM UTC, original submission:
Hello,
I am running Octave 4.0.0 under Windows 7/64bit and experience a problem when saving a plot.
The figure is created using the contourf command. When I save the file to PDF using the print command, the filled areas show the wrong colors, when compared to the colorbar.
This occurs for the graphics_toolkit 'fltk' and 'qt'; 'gnuplot' works fine, even though it messes up the xlabel und ylabel positions.
Besides, there appear to be artifacts within the filled areas.
Please advise.
Kind regards,
Michael
|