Fri 18 Nov 2016 05:50:24 AM UTC, comment #11:
The original examples work for me in Linux with 4.2.0. Closing report.
|
Fri 14 Dec 2012 01:15:44 PM UTC, comment #10:
If this is another example of the long-standing timing
problem in fltk it might be better to change the summary
to show this, and somehow try to track down the source
of this problem. I have tried to isolate the problem,
but have not succeeded.
It is a serious defect that printed plots continue to be
rendered incorrectly.
|
Fri 14 Dec 2012 11:41:35 AM UTC, comment #9:
No, I was too quick to draw a conclusion. The resizing command works with heights bigger than the displays height only when the figure spreads over more than one workspaces. So this may be indeed a separate bug related to a fltk restriction. Probably there will be some workaround, but I am not very experienced in fltk.
|
Fri 14 Dec 2012 11:22:14 AM UTC, comment #8:
I do not agree that this is a restriction of fltk/gl2ps.
If I comment out the setting of position in print.m:
% set (opts.figure, "position", fpos);
I can print the attached file with:
plot(1,1)
fpos = get (gcf, "position");
set (gcf, "position", [fpos(1),fpos(2),fpos(3),2000])
print('-dpng', '/tmp/test.png')
Actually I suspect that this issue is just another manifestation of a race condition between fltk and octave, as I have described it in detail here:
https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-June/028580.html
Other manifestations of this fundamental bug are random output sizes depending e.g. if print is issued interactively or in a script or if "waits" and "drawnows" are added in the code.
(file #27094)
|
Fri 17 Feb 2012 11:41:10 PM UTC, comment #7:
A future toolkit, such as Qt, may fix this so, I've modified the status to "Postponed"
|
Fri 17 Feb 2012 01:45:48 AM UTC, comment #6:
Changing the summary to better describe the problem.
|
Tue 14 Feb 2012 07:01:00 PM UTC, comment #5:
I ran the script on both MacOS 10.7.3 and Ubuntu 10.04. Nothing is garbled for me.
|
Tue 14 Feb 2012 05:02:50 PM UTC, comment #4:
For me this is now all garbled (using your script with octave version 8de863b7126b tip). See attached.
(file #25063, file #25064, file #25065, file #25066)
|
Tue 14 Feb 2012 02:01:49 AM UTC, comment #3:
I looked at this again. The problem for me is that my fltk window size is limited by my display. So when the print() command requests a window height of 1200 it is truncated.
To confirm I modified my script.
Both gnuplot and fltk give equivalent results.
I'm marking this as "won't fix" because this is a limitation imposed by the combination of fltk and gl2ps.
|
Mon 13 Feb 2012 10:47:33 PM UTC, comment #2:
The interesting thing is that all depends on whether the commands are issued interactively (_i) or as the script (_s). I attach 4 files here only one of which gives the expected result, namely bar_s.png. Please note the slight difference at the bottom corner of foo.
(file #25056, file #25057, file #25058, file #25059)
|
Thu 02 Feb 2012 08:13:59 PM UTC, comment #1:
I'll updated my sources.
Gnuplot still works correctly, but now neither fltk plot is correct. The results are essentially the same, but the plot has retained the default aspect ratio.
|
Thu 02 Feb 2012 07:53:36 PM UTC, original submission:
Using gnuplot, the example below gives me two plots what are each the correct size.
With fltk, the first is correct, but the 2nd is not. For me on MacOS X, the 2nd produces a sombrero with the proper aspect ratio, but it only fills the UL quadrant of 900 × 886 plot. The size should be 900 x 1200.
I'm running the default branch, and my tip is
|