Sun 22 Feb 2015 07:19:01 PM UTC, comment #24:
Closing report.
|
Sun 22 Feb 2015 06:07:40 PM UTC, comment #23:
This bug is marked as fixed on the wiki but still open here. Are there any remaining issues (that are not separate reports) or can this be closed as fixed?
|
Mon 09 Feb 2015 09:35:24 PM UTC, comment #22:
John: the save and save as options seem to work.
But, is untitled.eps a good default filename?
Maybe "Figure_n.pdf" where n is the figure number?
At least, I would prefer .pdf as default suffix. Others may
have other preferences.
Michael
|
Sun 08 Feb 2015 11:59:19 PM UTC, comment #21:
John,
I tried a few print("xxx.pdf") commands
using GUI and Qt and it looks good!
This is a great step forward!
I will do some more testing, but the figures I
did already used subplot, and various things
that used to produce problems, so...
Michael
|
Sun 08 Feb 2015 09:57:28 PM UTC, comment #20:
The problem is with Windows only. It seems to be something with gl2ps. We can open up a new report or re-title this one.
|
Sun 08 Feb 2015 09:30:10 PM UTC, comment #19:
I checked in my changes here:
http://hg.savannah.gnu.org/hgweb/octave/rev/35bca657d74d
If the redering problem happens with PostScript output, then it seems the bug would be in gl2ps or the way we are calling it.
Maybe comparing PostScript files generated on Windows and Linux systems would help to diagnose the problem?
|
Sun 08 Feb 2015 09:17:18 PM UTC, comment #18:
Is the line dropout problem a Windows-only problem? I don't see it on my Debian system.
|
Fri 30 Jan 2015 12:53:05 PM UTC, comment #17:
Patch didn't do anything different:
Result is a png file that has line dropout.
|
Thu 29 Jan 2015 09:42:55 PM UTC, comment #16:
The output to std::out is only debugging output.
I think GL2PS_UNINITIALIZED and GL2PS_ERROR should later raise an error.
|
Thu 29 Jan 2015 09:33:47 PM UTC, comment #15:
Is the output to std::cout in the patch just there for debugging? Or should it become Octave warnings or errors instead of just being sent to std::cout?
|
Thu 29 Jan 2015 08:37:33 PM UTC, comment #14:
Was thinking the same after JWE said code was all the same.
https://savannah.gnu.org/bugs/index.php?44125
Will try the patch
|
Thu 29 Jan 2015 08:28:46 PM UTC, comment #13:
The problem with part of the line dropping out on Windows should be reported as a new bug. I have a fairly recent dev version of MXE-Octave running on a Windows XP virtual machine and it has the same error with the FLTK toolkit. I tried adding a few other lines--horizontal, vertical-- and sometimes they don't show up in the output at all.
|
Thu 29 Jan 2015 08:24:52 PM UTC, comment #12:
@John Donoghue: Your problem looks like #42534.
Could you try the attached temporary gl2ps.patch which adds glFinish (which I think is very important and could be the cause for the missing lines) and adds some debug outputs.
(file #32945)
|
Thu 29 Jan 2015 08:15:45 PM UTC, comment #11:
Well that would explain why both qt and fltk prints are not working correctly for me in windows with 4.1.0+.
Im doing a new 3.8.2 build just to make sure that I havent updated any other libraries that are effecting the 4.1.0 but weren't updated when I had created the 3.8.2 build.
|
Thu 29 Jan 2015 07:15:05 PM UTC, comment #10:
Printing should work exactly the same for OpenGL plots with either the Qt or FLTK widgets. My changes primarily set up dispatching of the print command inside the QtHandles code. Ultimately it does exactly the same thing to print as the FLTK code. I'll create a single function that does that job and eliminate the duplicate code.
|
Thu 29 Jan 2015 06:57:17 PM UTC, comment #9:
I tried set (0, "DefaultFigure__enhanced__", "off") but no difference.
Display in plot window is fine. Its the generated file that is not correct.
|
Thu 29 Jan 2015 06:41:40 PM UTC, comment #8:
If display is the problem, try disabling anti-aliasing and see if that makes a difference. I'm not particularly a fan of the basic anti-aliasing that OpenGL provides so I have this in my .octaverc file.
# Disable anti-aliasing in FLTK
set (0, "DefaultFigure__enhanced__", "off");
|
Thu 29 Jan 2015 06:28:54 PM UTC, comment #7:
Attached .eps files using fltk with 3.8.2 vs 4.1.0+
(file #32942, file #32943)
|
Thu 29 Jan 2015 06:17:53 PM UTC, comment #6:
Using octave4.1.0+, id 3da4b083e0b8 with patch applied.
Works in windows gui, although there is an issue:
Running:
plot([1:10)
print t.png
The displayed plot line is NOT solid from 1,1 to 10,10
1,1-6,6 is good, there is a gap with a faint line between 6,6-9,9 and then
9,9-10,10 is solid again.
It also occurs using the fltk toolkit, and also saving as .eps etc.
So isn't just a qt issue.
Gnuplot doesn't do it.
Running a mxe-octave 3.8.2 version with fltk works fine.
|
Thu 29 Jan 2015 02:31:42 PM UTC, comment #5:
I'm attaching a preliminary patch for this problem. It seems to work for me.
(file #32938)
|
Wed 11 Jun 2014 02:01:52 PM UTC, comment #4:
@Rik:
What about updating the title to make this bug a reference for qt specific printing issue?
|
Wed 11 Jun 2014 01:57:33 PM UTC, comment #3:
Confirmed. I don't think anyone has worked on developing the print backend for the qt graphics toolkit.
Until that is done, you will need to use one of the other toolkits if you intend to print. Either 'graphics_toolkit fltk' or 'graphics_toolkit gnuplot' before plotting and printing.
|
Wed 11 Jun 2014 08:55:38 AM UTC, comment #2:
Hi, using the fltk toolkit is OK!
>> close all
>> graphics_toolkit ('fltk')
>> peaks
XOpenIM() failed
>> print peaks.jpg
>>
.... 11. Jun 10:49 peaks.jpg
greets
Wolfgang
|
Wed 11 Jun 2014 08:18:18 AM UTC, comment #1:
If you are using a recent dev source tree, you are also probably using "qt" graphics_toolkit when the gui is launched. It is a known limitation of "qt" toolkit that printing doesn't work but AFAIK it hadn't been reported up to now.
The reason why "octave ppeaks.m" works is that then the gui is not launched and "fltk" toolkit is used instead.
If you can confirm that the following snippet works in the gui terminal,
then this bug report could be retitled something like "printing doesn't work with qt graphics_toolkit" for clarity.
|
Tue 10 Jun 2014 09:22:12 PM UTC, original submission:
failure case:
=============
NO peaks.jpg, NO error/warning messages
good case:
==========
OK: peaks.jpg
changeset: 18817:096b1a159d1f
seen on f20 and ubuntu14.04
|