(
Jump to the original submission)
Mon 16 Feb 2015 12:31:21 AM UTC, comment #12:
On a new build it appears to work ok, so maybe I had something out of sync on my build.
Works for me.
|
Sun 15 Feb 2015 08:49:50 PM UTC, comment #11:
worked for me. Did not see any dropout. Which command failed for you?
|
Sun 15 Feb 2015 06:30:55 PM UTC, comment #10:
Doesnt fix it for me - same dropout occurs, although perhaps the line is a little darker.
|
Sat 14 Feb 2015 05:34:36 PM UTC, comment #9:
Applied patch in bug #44111. This now works for me on my MXE octave build. I have marked the bug as Ready for Test and if someone else can verify that the problem is gone then I will close this bug.
|
Fri 13 Feb 2015 11:07:07 PM UTC, comment #8:
This bug is fixed if we apply the patch in bug #44111. The problem is that we have not be using the gl2ps POLYGON_OFFSET correctly.
|
Mon 02 Feb 2015 05:03:07 PM UTC, comment #7:
What are the performance implications of just using GL2PS_BSP_SORT all the time?
According to the documentation for gl2ps:
I changed from NO_SORT to SIMPLE_SORT to correctly handle the 'layer' attribute for axes (either in front of or behind the 2-D objects on the screen). I would think that most of the time the GL2PS_BSP_SORT wouldn't actually be much more time consuming for your average 2-D plot. However, there are probably some situations, like a scatter plot with 99 points, which might show a difference.
If benchmarking doesn't show much of a change I would be fine changing the default to BSP_SORT.
|
Fri 30 Jan 2015 08:12:16 PM UTC, comment #6:
If I run drawnow as per previous comment (your patch is still applied) then the resulting out.eps looks good!
|
Fri 30 Jan 2015 05:43:16 PM UTC, comment #5:
Do you see a difference if you force GL2PS_BSP_SORT?
If I remember correctly gl2ps_sort has changed from GL2PS_NO_SORT to GL2PS_SIMPLE_SORT between 3.8.2 and 4.1. cset 652d9ed6f88d
|
Fri 30 Jan 2015 04:21:42 PM UTC, comment #4:
I just verified - rebuilding 3.8.2 using all the same other libraries (ghostscript, libpng, epstool etc) as I had built the 4.1.0+ version.
In 3.8.2, the printed plot in fltk displays ok. In 4.1.0+, it does not.
|
Fri 30 Jan 2015 08:47:12 AM UTC, comment #3:
Thats interesting. All other reporter of this (missing or broken lines with MXE-Octave on Windows with FLTK or Qt) had the same problem on Octave 3.8.2 and 4.1.0.
For some of them installing the Mesa driver helped: http://wiki.octave.org/FAQ#Missing_lines_when_printing_under_Windows_with_OpenGL_toolkit_and_Intel_integrated_GPU
|
Thu 29 Jan 2015 09:51:51 PM UTC, comment #2:
Maybe - I do have a Intel HD Graphics 3000.
fltk printing worked fine in octave 3.8.2 but not the dev 4.1.0.
|
Thu 29 Jan 2015 09:46:18 PM UTC, comment #1:
Is this a duplicate of bug #42534?
|
Thu 29 Jan 2015 08:36:33 PM UTC, original submission:
Spawned from https://savannah.gnu.org/bugs/?42537.
Printing using fltk has lines that display dropouts in the thickness of the line.
Can be seen by:
Printing was working ok in mxe-octave 3.8.2.
|
(Note: upload size limit is set to 16384 kB, after insertion of the required
escape characters.)
Attach File(s):
Comment:
No files currently attached
Depends on the following items
Digest:
bug dependencies.
Items that depend on this one: None found
Follow 6 latest changes.