bugGNU Octave - Bugs: bug #34720, print() for FLTK produces wrong...

 
 

bug #34720: print() for FLTK produces wrong size and scale

Submitter:  Muhali <muhali>
Submitted:  Tue 01 Nov 2011 11:15:38 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

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

Ben Abbott <bpabbott>
Group Member
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.

Rik <rik5>
Group administrator
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.

Ben Abbott <bpabbott>
Group Member
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.

John W. Eaton <jwe>
Group administrator
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.


Ben Abbott <bpabbott>
Group Member
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,

Ben Abbott <bpabbott>
Group Member
Mon 21 Nov 2011 02:26:12 AM UTC, comment #18: 

The patch below improves the situation.


diff --git a/scripts/plot/print.m b/scripts/plot/print.m
--- a/scripts/plot/print.m
+++ b/scripts/plot/print.m
@@ -289,6 +289,24 @@
     props(1).name = "position";
     props(1).value = {fpos};
     fpos(3:4) = opts.canvas_size;
+    if (! strcmp (get (opts.figure, "__graphics_toolkit__"), "gnuplot"))
+      ## FIXME - This should not be needed.
+      ##
+      ##         Comments by bpabbott:
+      ##
+      ##         Without the drawnow(), printing from a script results in an
+      ##         image whose height is shortened by the status bar height.
+      ##         With the added drawnow(), and printing from a script, the
+      ##         image height (H) is too tall by H/24 or 17.5 pixels for the
+      ##         default figure height (420 pixels).
+      ##
+      ##         My Octave was built on MacOS X, using MacPorts for dependencies
+      ##         and with fltk-aqua-1.1.10.
+      ##
+      ##         My FLTK windows do not display the menu bar, and the resulting
+      ##         plot area is too large by half the status-bar height (10 pixels)
+      drawnow ()
+    endif
     set (opts.figure, "position", fpos);

     ## Set figure background to none. This is done both for
diff --git a/src/graphics.cc b/src/graphics.cc
--- a/src/graphics.cc
+++ b/src/graphics.cc
@@ -3237,9 +3237,9 @@
     {
       Matrix old_bb, new_bb;

-      old_bb = get_boundingbox ();
+      old_bb = get_boundingbox (true);
       position.set (v, true, do_notify_toolkit);
-      new_bb = get_boundingbox ();
+      new_bb = get_boundingbox (true);

       if (old_bb != new_bb)
         {


Ben Abbott <bpabbott>
Group Member
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


graphics_toolkit fltk
plot (rand (2))
print (sprintf ("-r%d", round (get (0, "screenpixelsperinch"))), "test.png")


The result should be 800x600 but is 800x625 from the command line and 600x527 when run as a script (My screenpixelsperinch is 99.898).

Ben Abbott <bpabbott>
Group Member
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).


$ diff --git a/src/DLD-FUNCTIONS/__init_fltk__.cc b/src/DLD-FUNCTIONS/__init_fltk__.cc
--- a/src/DLD-FUNCTIONS/__init_fltk__.cc
+++ b/src/DLD-FUNCTIONS/__init_fltk__.cc
@@ -667,7 +667,8 @@
    begin ();
     {

-      canvas = new OpenGL_fltk (0, 0, ww, hh - status_h, number ());
+      // canvas = new OpenGL_fltk (0, 0, ww, hh - status_h, number ());
+      canvas = new OpenGL_fltk (0, 0, ww, hh, number ());

       uimenu = new fltk_uimenu (0, 0, ww, menu_h);
       uimenu->hide ();


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).


--- a/src/graphics.cc
+++ b/src/graphics.cc
@@ -189,7 +189,7 @@
 static double
 default_screenpixelsperinch (void)
 {
-  return (display_info::x_dpi () + display_info::y_dpi ()) / 2;
+  return 72.0;
 }


Ben Abbott <bpabbott>
Group Member
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.


clear all
close all
graphics_toolkit fltk
figure (1)
plot (rand (2))
print -depsc foo.eps
print -r72 foo.png
paperposition = get (gcf, "paperposition");
canvas_size = 72 * paperposition(3:4);


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


$ grep -in "= 20" __init_fltk__.cc
928:  static const int status_h = 20;
931:  static const int menu_h = 20;


I don't see a menu bar on my figure, so looking at the status_h, I see


$ grep -in "status_h" __init_fltk__.cc
665:    size_range (4*status_h, 2*status_h);
670:      canvas = new OpenGL_fltk (0, 0, ww, hh - status_h, number ());
675:      bottom = new Fl_Box (0, hh - status_h, ww, status_h);
680:      autoscale = new Fl_Button (0, hh - status_h, status_h, status_h, "A");
684:      togglegrid = new Fl_Button (status_h, hh - status_h, status_h,
685:                                  status_h, "G");
689:      panzoom = new Fl_Button (2 * status_h, hh - status_h, status_h,
690:                               status_h, "P");
694:      rotate = new Fl_Button (3 * status_h, hh - status_h, status_h,
695:                              status_h, "R");
702:      help = new Fl_Button (4 * status_h, hh - status_h, status_h,
703:                            status_h, "?");
707:      status = new Fl_Output (5 * status_h, hh - status_h,
708:                              ww > 2*status_h ? ww - status_h : 0,
709:                              status_h, "");
928:  static const int status_h = 20;
1090:        pos(1) = h () - status_h - menu_h - py;
1165:    pos(3) = hh - status_h - menu_h;
1173:    Fl_Window::resize (pos(0), pos(1), pos(2), pos(3) + status_h + menu_h);


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?


$ grep -in "menu_h" __init_fltk__.cc
672:      uimenu = new fltk_uimenu (0, 0, ww, menu_h);
785:                        canvas->y () + menu_h,
787:                        canvas->h () - menu_h);
798:                        canvas->y () - menu_h,
800:                        canvas->h () + menu_h);
931:  static const int menu_h = 20;
1090:        pos(1) = h () - status_h - menu_h - py;
1165:    pos(3) = hh - status_h - menu_h;
1173:    Fl_Window::resize (pos(0), pos(1), pos(2), pos(3) + status_h + menu_h);


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.

Ben Abbott <bpabbott>
Group Member
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).


plot([1 1]);
print foo.png


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.


Ben Abbott <bpabbott>
Group Member
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.

Muhali <muhali>
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.


Ben Abbott <bpabbott>
Group Member
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.



Ben Abbott <bpabbott>
Group Member
Thu 03 Nov 2011 06:29:44 PM UTC, comment #10: 

I see the shifting behavior also with plotting only (no printing):


figure(1) ;
plot([1 1]);
pause(0.0001);
plot([1 1]);
figure(2);
plot([1 1]);


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).

Muhali <muhali>
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.

Ben Abbott <bpabbott>
Group Member
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?

Muhali <muhali>
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).


Ben Abbott <bpabbott>
Group Member
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;


changeset:   13804:a2e158c3451f
tag:         tip
user:        John W. Eaton <jwe@octave.org>
date:        Thu Nov 03 05:30:45 2011 -0400
summary:     provide the waitbar function


The plots I get now are attached as foo-Macports2.png and foo_paused-MacPorts2.png.


Ben Abbott <bpabbott>
Group Member
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?



Ben Abbott <bpabbott>
Group Member
Thu 03 Nov 2011 04:10:10 AM UTC, comment #4: 

This code

plot([1 1]);
pause(2) ;
plot([1 1]);
print foo_pause.png ;

produces foo_pause.png (the shrunk version) while this code

plot([1 1]);
plot([1 1]);
print foo.png ;

produces foo.png (the correct one), both figures attached.

I am using the following octave version:
parent: 13760:1d97688f8522 tip

Muhali <muhali>
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?


Ben Abbott <bpabbott>
Group Member
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:


plot(rand(2,2)) ;
pause(2) ;
plot(rand(2,2)) ;
print foo.png ;


Sorry for the noise.

M.

Muhali <muhali>
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.

Muhali <muhali>
Tue 01 Nov 2011 11:15:38 PM UTC, original submission:  

For a simple two-line plot and print sequence like


plot(rand(2,2)) ;
print foo.svg


the right y-axis gets out of the canvas. This does not happen with only one line.

M.

Muhali <muhali>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #24428:  Octave-3.4.3-fltk-predrawnow.png added by bpabbott (10KiB - image/png - plots from the stable branch)
file #24429:  Octave-3.4.3-fltk-postdrawnow.png added by bpabbott (8KiB - image/png - plots from the stable branch)
file #24425:  go_test.m added by bpabbott (646B - application/octet-stream)
file #24295:  figure1-paused.png added by bpabbott (41KiB - image/png - with tip b3cdef33ac0e)
file #24296:  figure2.png added by bpabbott (41KiB - image/png - with tip b3cdef33ac0e)
file #24291:  figure1-paused.png added by bpabbott (41KiB - image/png - figures with tip a2e158c3451f)
file #24292:  figure2.png added by bpabbott (41KiB - image/png - figures with tip a2e158c3451f)
file #24284:  foo-MacPorts.png added by bpabbott (10KiB - image/png - plots on MacOS 10.7 with FLTK 1.3 from MacPorts)
file #24285:  foo_pause-MacPorts.png added by bpabbott (10KiB - image/png - plots on MacOS 10.7 with FLTK 1.3 from MacPorts)
file #24281:  foo_pause.png added by muhali (9KiB - image/png)
file #24282:  foo.png added by muhali (10KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by bpabbott
  • -email is unavailable- added by bpabbott
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by muhali (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 25 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-02-16 bpabbott StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2012-01-09 rik5 Severity5 - Blocker 3 - Normal
    2011-11-22 bpabbott Attached File- Added Octave-3.4.3-fltk-predrawnow.png, #24428
        Attached File- Added Octave-3.4.3-fltk-postdrawnow.png, #24429
    2011-11-22 bpabbott Attached File- Added go_test.m, #24425
        Attached File- Added Octave-3.5.0+-fltk-predrawnow.png, #24426
        Attached File- Added Octave-3.5.0+-fltk-postdrawnow.png, #24427
        Severity3 - Normal 5 - Blocker
    2011-11-13 bpabbott Summaryplot box shifts when printing with FLTK print() for FLTK produces wrong size and scale
    2011-11-10 bpabbott Carbon-Copy- Added -email is unavailable-
    2011-11-09 bpabbott Carbon-Copy- Added -email is unavailable-
    2011-11-03 bpabbott Attached File- Added figure1-paused.png, #24295
        Attached File- Added figure2.png, #24296
    2011-11-03 bpabbott Attached File- Added figure1-paused.png, #24291
        Attached File- Added figure2.png, #24292
    2011-11-03 bpabbott Attached File- Added foo-MacPorts2.png, #24286
        Attached File- Added foo_pause-MacPorts2.png, #24287
    2011-11-03 bpabbott Attached File- Added foo-MacPorts.png, #24284
        Attached File- Added foo_pause-MacPorts.png, #24285
        Item GroupNone Incorrect Result
        StatusNone Confirmed
        Summaryprinting svg gets out of canvas plot box shifts when printing with FLTK
    2011-11-03 muhali Attached File- Added foo_pause.png, #24281
        Attached File- Added foo.png, #24282

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code