Thu 16 Feb 2012 12:44:05 AM UTC, comment #24:
I've pushed a changeset that fixes this for me.
http://hg.savannah.gnu.org/hgweb/octave/rev/ba01a38bc5c1
|
Mon 09 Jan 2012 07:08:01 PM UTC, comment #23:
I'm dropping the priority of the bug below 4 so this will no longer be a blocker for the 3.6.0 release.
|
Wed 04 Jan 2012 05:31:35 PM UTC, comment #22:
I agree. I think it best to ignore this for the 3.6.0 release.
Any objection to reversing the patch below in the default branch ?
http://hg.savannah.gnu.org/hgweb/octave/diff/1367f2db49a2/src/graphics.cc
Meaning, we'd reinstate this one in default ?
http://hg.savannah.gnu.org/hgweb/octave/diff/5c2096009c43/src/graphics.cc
If this can be done, then I'll modify print.m to include the drawnow() prior to changing the figure position. My guess is this is fixing an error that hasn't yet been isolated, so a comment should also be included indicating why the drawnow() has been added.
|
Wed 04 Jan 2012 04:03:36 PM UTC, comment #21:
Has there been any progress on this problem?
If not, I'm likely to ignore it for the 3.6.0 release since plotting with OpenGL+FLTK is not yet the default.
|
Tue 22 Nov 2011 11:58:35 PM UTC, comment #20:
I've marked this as a block for the release of 3.6 because it worked much better for me in 3.4. Thus, it is a reversion for me.
|
Tue 22 Nov 2011 11:54:01 PM UTC, comment #19:
I've attached go_test.m and two png's produced by this script with tip 2af665333b86.
I'll follow up with the plots produce from the stable branch.
(file #24425, file #24426, file #24427)
|
Mon 21 Nov 2011 02:26:12 AM UTC, comment #18:
The patch below improves the situation.
|
Tue 15 Nov 2011 06:50:58 PM UTC, comment #17:
I just noticed that print() behaves differently when run from the command line than it does when run as part of a script.
The examples I gave below were all run as scripts.
When I run a simple example from the command line
The result should be 800x600 but is 800x625 from the command line and 600x527 when run as a script (My screenpixelsperinch is 99.898).
|
Sun 13 Nov 2011 07:03:11 PM UTC, comment #16:
After looking at this more closely, I think the original problem has been resolved, but there remain two problems with the FLTK backend. I've changed the "Summary" to give a better description.
My display has a screen resolution (screeenpixelsperinch) of 99.898. For my comments below, it is sufficient to treat my screen's resolution as 100 dpi.
First, the height of the graphic output produced using print() is shorter than it should be. For my case the bottom of the image appears to be off by the height of the status bar. If I understand the code correctly, the height of the status bar is set in _init_fltk_.cc to be 20 points. For my resolution this translates to 28 pixels. When I produce output with "-r100" I expect an image size of 800x600, but am getting 800x572.
This I am able to correct by the change below (however, I'm not confident this is the proper fix).
Second, the scale of the figure's graphics objects is off by screenpixelsperinch / 72 (with the UL corner being the origin). The result is that the output appears cropped. This effect appears to have been introduced in the changeset below.
http://hg.savannah.gnu.org/hgweb/octave/rev/4f112bebd474
I don't see how to fix this in a proper way, but if I force Octave to use 72 dpi for the display, then the output produced is consistent with a display of 72 dpi. The diff for that is below. With this change, the status bar is not present in the displayed window (the area is gray and empty).
|
Thu 10 Nov 2011 01:10:49 AM UTC, comment #15:
On my prior comment (#14), my figure size wasn't set to the default (I had modified th e default in my ~/.octaverc)
I've constructed a simple test with the stand figure defaults. With the following script I get a png with 576 × 412 pixels and an eps with 576 × 412 points.
However, the proper size is indicated by "canvas_size" which is 576 x 432.
So the vertical height is off by 20. Grepping _init_fltk_.cc, I see
I don't see a menu bar on my figure, so looking at the status_h, I see
It looks to me like some (all?) of these status_h adjustments are no longer needed after the changeset below.
http://hg.savannah.gnu.org/hgweb/octave/diff/4f112bebd474/src/DLD-FUNCTIONS/__init_fltk__.cc
Perhaps some of the menu_h adjustments also need to be pruned?
I'm not familiar with this part of the code, and am hesitant to make changes (for fear of unintended consequences).
I've cc'd jwe who committed the changeset I mentioned above.
|
Wed 09 Nov 2011 09:01:23 PM UTC, comment #14:
The "canvas_size" parameter specifies the requested size of the output. Changing this should not change the relative position of the axes box.
I reviewed the result returned by print_parse_opts for the simple example below, and it looks correct to me (in particular the pageoffset is zero for bit mapped output, as it should be).
The bit mapped output is derived from eps output. So I checked that this conversion (done by ghostscript) did not introduce the offset, by examining the eps output. Since the eps output also includes the offset, the problem must be in the output of the eps.
The BBOX in the eps file should be [8, 6] * 72 = [576 432] but is actually [576 450].
It looks like the problem is either with the FLTK part of the octave code, or with FLTK itself (or maybe gl2ps).
I have faint recollection that we once had a problem where the status bar at the bottom of the FLTK window was being included in the output. It looks to me as if this may be happening again (the proportions are about correct).
I think Shai fixed this before (?). I've cc'd him.
|
Wed 09 Nov 2011 07:01:13 PM UTC, comment #13:
I think I have narrowed it down to the print, especially the _print_parse_opts_ function.
From that it obtains a number of parameters, such as 'canvas_size', which is uses for a couple of subsequent 'set' statements.
I am not too familiar with what's going on here, but simply removing the set commands cleared the issue for me.
|
Thu 03 Nov 2011 06:49:16 PM UTC, comment #12:
With tip b3cdef33ac0e, I still get identical figures, but they are not correct. The images of each figure are attached.
If I print each of them, the resulting files still look as indicated by 24286 and 24287, and after printing the figure windows now look as indicated by 24291 and 24292.
(file #24295, file #24296)
|
Thu 03 Nov 2011 06:39:10 PM UTC, comment #11:
My tip is a2e158c3451f, and I do not see a shift in the plots (I've attached pngs of my figure windows).
I'm two changesets behind, I'll pull and build with those and report. back.
(file #24291, file #24292)
|
Thu 03 Nov 2011 06:29:44 PM UTC, comment #10:
I see the shifting behavior also with plotting only (no printing):
This is with the current tip (13804:4f112bebd474).
I am not sure how/whether it is related to the issue described in my original post (plot gets outside canvas).
|
Thu 03 Nov 2011 06:24:45 PM UTC, comment #9:
The first part of the revision numer "13803" can be different for different repositories. Its only the second part that is expected to stay in sync.
In my prior comment, I meant that the files produced with Ubuntu / Mesa / FLTK 1.1.10 and MacOS / OpenGL / FLTK 1.3.0 were identical. There remains a difference in the vertical location of the x-axis when comparing foo-MacPorts2.png and foo_paused-MacPorts2.png.
|
Thu 03 Nov 2011 04:55:53 PM UTC, comment #8:
Your results with foo-MacPorts2.png and foo_paused-MacPorts2.png are actually slightly different (small shift of x-axis in the former).
I am using fltk-1.3.0 and 7.libgl1-mesa-dev 7.1-5 from debian.
How is that your changeset is
changeset: 13804:a2e158c3451f
while the repository revision is 13803?
|
Thu 03 Nov 2011 02:03:17 PM UTC, comment #7:
I compared MacOS 10.7 with FLTK 3 to Ubuntu 10.04 with FLTK 1.1.10 and Mesa 7.7.1. I'm getting identical results (foo-MacPorts2.png and foo_paused-MacPorts2.png).
|
Thu 03 Nov 2011 12:51:51 PM UTC, comment #6:
There have just been some changes to the backend in the last day that impact this behavior for me. My tip is now;
The plots I get now are attached as foo-Macports2.png and foo_paused-MacPorts2.png.
(file #24286, file #24287)
|
Thu 03 Nov 2011 12:36:14 PM UTC, comment #5:
Looking at the plots, I see you're using the FLTK backend. I now see you indicated that in the category above (I missed that earlier).
Running your examples, I do see differences, but not the same as you. For me the paused version looks best, but the axis box is shifted upward from its proper position.
I've attached the two plots. I've appended MacPorts to the names to avoid confusion and to indicate where I'm getting my dependencies (FLTK for example).
I'm not proficient enough in c/c++ or fltk/opengl to be helpful in tracking down this problem. So we'll have to wait for someone with more experience.
I've changed the title in the hope of attracting the right individual.
In the meantime, I'm using the fltk-devel-1.3.x-r8635 (aqua) port with the OpenGL bundled with MacOS 10.7. What version of Mesa and FLTK are you using?
(file #24284, file #24285)
|
Thu 03 Nov 2011 04:10:10 AM UTC, comment #4:
This code
produces foo_pause.png (the shrunk version) while this code
produces foo.png (the correct one), both figures attached.
I am using the following octave version:
parent: 13760:1d97688f8522 tip
|
Thu 03 Nov 2011 01:25:09 AM UTC, comment #3:
I'm unable to duplicate the problem.
Do both scripts produce the problem?
Please attach the foo.svg and foo.png files for us to examine. Also, just to be sure please confirm you are building Octave yourself from the mercurial sources. If so what is your tip?
|
Wed 02 Nov 2011 07:04:42 PM UTC, comment #2:
update 2:
it also seems important that there is a pause between the two plot commands (e.g. in interactive mode). All in all, the shrunk printout appears from this script:
Sorry for the noise.
M.
|
Wed 02 Nov 2011 05:37:49 PM UTC, comment #1:
update:
a) It only shows this behavior after issuing the plot command twice.
b) The output format is inessential (same for png etc.)
M.
|
Tue 01 Nov 2011 11:15:38 PM UTC, original submission:
For a simple two-line plot and print sequence like
the right y-axis gets out of the canvas. This does not happen with only one line.
M.
|