Thu 09 Nov 2017 10:40:26 PM UTC, comment #11:
Actually I spoke too soon, the workaround I provided is not equivalent to the "-S" option so it can't be used as a replacement for the current implementation.
The "-S" options changes the size of the figure while the workaround mainly changes the aspect ratio and the resolution (for raster formats only).
|
Thu 09 Nov 2017 06:04:19 AM UTC, comment #10:
We don't need to support this option for Matlab compatibility, but would it be nice to keep it for quickly specifying the output size? I understand that the equivalent scaling can be had by changing the paperposition property, but why can't Octave just do that for the user by specifying this single argument to print?
|
Wed 08 Nov 2017 04:49:09 PM UTC, comment #9:
@juanpi: I'd like to deprecate the "-S" option:
- It is easy to do the same job with the "paperposition" property and this technique avoids having to scale figures at very large size.
- Matlab does not have it so there is no compatibility problem
Do you have any objection.
|
Thu 29 Dec 2016 09:22:32 PM UTC, comment #8:
This issue is still present in Octave 4.2.0.
Running the sample code from comment #0 still produces one uncropped and two cropped png images on my Ubuntu PC.
|
Wed 10 Jun 2015 10:09:12 PM UTC, comment #7:
Thanks Juan Pablo, with these additional informations I can trigger the bug using very large figure size, e.g.
Not only even the first figures file is incorrect, but the figure window itself ends maximized.
Retitling again.
|
Wed 10 Jun 2015 07:05:22 PM UTC, comment #6:
Hi,
I tried all possible combinations of pause and drawnow and the error appears all the time.
Indeed fltk and gnuplot do not show the issue.
The for loop is not needed. The script is not even needed. Once a plot is printed with a different resolution the followings are not correct. Calling clf doesn't solve the problem, one needs to close the figure and create a new one.
Printing to sizes smaller than the screen size doesn't trigger the problem.
|
Wed 10 Jun 2015 01:06:01 PM UTC, comment #5:
@Juan Pi: the fact that it works offscreen (and I guess it also works with fltk) tells us that it is probably a threading issue like most of the problems we currently have with printing.
- Can you try to move the pause before/after plot, and do the same with a "drawnow ()"?
- Can you test if the for loop is needed, e.g run the following from a script (copy/paste in the command window may not trigger the bug):
- The bug is probably triggered by the fact that you change the dpi. Can you check using the default resolution (without -S... option).
|
Wed 10 Jun 2015 11:13:56 AM UTC, comment #4:
Let me add that I am running Ubuntu 15.04 with nvidia driver 340.76
|
Wed 10 Jun 2015 11:09:25 AM UTC, comment #3:
Hi,
The extra pause doesn't solve the issue.
I am sorry to have misunderstood "off-screen", I thought it meant "to disk" or "to file". Anyways, if I run the modified code
I get the right plots. If the image is visible I do not get the rigght plot, even if I add a pause. It seems that the screen doesn't resize after the s800,600 command.
|
Wed 10 Jun 2015 11:04:32 AM UTC, comment #2:
I also couldn't reproduce this behavior using MXE-Octave on Win7.
|
Wed 10 Jun 2015 10:24:29 AM UTC, comment #1:
Hi,
I can't reproduce this behavior using a self compiled Octave 4.0 on linux mint 17.1: all 3 png are identical and conform to what I expect. There may be a timing issue that is raised depending on the graphics capabilities of your hardware.
Can you add add a "pause (1)" after the "print" statement and report back?
BTW why did you mention "off screen" plots in the title? We have been using this terminology when printing invisible figures ("visible" = "off").
|
Tue 09 Jun 2015 05:50:07 PM UTC, original submission:
The following code
Produces a first png figure that is correct but all sequential figures are trimmed. See attached figures
|