bugGNU Octave - Bugs: bug #37554, PaperPositionMode = 'auto' is...

 
 

bug #37554: PaperPositionMode = 'auto' is ignored for printing

Submitted by:  None
Submitted on:  Thu 11 Oct 2012 11:51:16 PM UTC  
 
Category: PlottingSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: Ready For TestAssigned to: None
Originator Name: Dov KrugerOriginator Email: -unavailable-
Open/Closed: OpenRelease: dev
Operating System: Any

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Thu 03 Jul 2014 06:45:39 PM UTC, comment #46:

I pushed the last submitted changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/2420a4f22998).

@Michael: If it is ok for you, I think we can close this bug report.

Pantxo Diribarne <pantxo>
Project Member
Tue 24 Jun 2014 04:34:51 PM UTC, comment #45:

I suppose this this bug report could be closed after the last patch has been pushed. Can someone take care of this please?

Thanks in advance.

Pantxo Diribarne <pantxo>
Project Member
Mon 02 Jun 2014 06:34:02 PM UTC, comment #44:

The latest version of this patch works for
me and provides separate asserts for each test
so in case of a failure it will be clear what
failed.

It would be good, I think to push this since
the current tests fail on my Fedora 20 system
and apparently on others.

The patch is in (file #31458)

Michael Godfrey <godfrey>
Tue 27 May 2014 08:03:09 PM UTC, comment #43:

I do think that this patch is clearer and
will reduce the effort required if there
is a failure in the future.

Thanks for the extra effort.

Michael Godfrey <godfrey>
Tue 27 May 2014 07:42:53 PM UTC, comment #42:

I attached a patch. %!test is split into 5 (at the expense of much redundant code) and tolerance is increased to 20*eps.

(file #31458)

Pantxo Diribarne <pantxo>
Project Member
Mon 26 May 2014 10:15:18 PM UTC, comment #41:

I think that it is more informative
to report failure for each test.
This would have made it simpler, at least
for me, to understand which tests were failing.

Related to this, I think that the fifth test
that you incresaed the tolerance on did not
fail on my system. Probably makes sense to
increase its tolerance anyhow.

Michael Godfrey <godfrey>
Mon 26 May 2014 09:41:43 PM UTC, comment #40:

It is written as one single test with multiple passing criteria: if one of the "assert" fails the whole test is considered failing.

Would you prefer separate tests, with one assert per test?

Pantxo Diribarne <pantxo>
Project Member
Mon 26 May 2014 09:10:13 PM UTC, comment #39:

I have no problem with the tolerances. So, the
failures can be viewed as fixed using 20*eps.

The fact that the tests are written in such a way that
if a test fails then all subsequent tests are skipped
(ut counted as passed) should be fixed.

If people think it is appropriate a new report
could be opened for this.

Michael Godfrey <godfrey>
Mon 26 May 2014 08:47:53 PM UTC, comment #38:

This isn't a matrix calculation where the accumulation of tolerances in the calculation is critically important.

If the paper position is calculated as 6"+4e-16 there isn't a printer anywhere that has that kind of accuracy. I would just increase the tolerance on the test and close the report.

Rik <rik5>
Project Administrator
Mon 26 May 2014 08:36:57 PM UTC, comment #37:

I can reproduce part of the failure (only the first assert fails) if set paperpositionmode "auto" at figure initialisation:

The test then involves more unit conversions. Here is an example that always fails for me:

Solving the above bug would probably involve concentrating all unit conversions in one place (which is currently far from being true).

I propose the following:

  • file another bug report with the above failure.
  • either mark the current test as xfail or increase the tolerance and then close this bug report.

Any thoughts?

Pantxo Diribarne <pantxo>
Project Member
Sun 25 May 2014 05:28:54 PM UTC, comment #36:

Pantxo:

I just ran the test, changing the 20* to 1*
What I found is that the test fails on the first 1*
%! hf = figure ("visible", "off");
%! unwind_protect
%! ## paperpositionmode "auto" converts figure size to paper units
%! set (hf, "units", "inches");
%! set (hf, "position", [0 0 4 5]);
%! set (hf, "paperunits", "centimeters");
%! psz = get (hf, "papersize");
%! fsz = [10.16 12.7];
%! pos = [(psz/2 .- fsz/2) fsz];
%! set (hf, "paperpositionmode", "auto");
%! assert (get (hf, "paperposition"), pos, eps)

and then skips the rest of the tests.
So, all 4 of the following tests fail:
%! ## paperpositionmode "auto" converts figure size to paper units
%! set (hf, "units", "inches");
%! set (hf, "position", [0 0 4 5]);
%! set (hf, "paperunits", "centimeters");
%! psz = get (hf, "papersize");
%! fsz = [10.16 12.7];
%! pos = [(psz/2 .- fsz/2) fsz];
%! set (hf, "paperpositionmode", "auto");
%! assert (get (hf, "paperposition"), pos, eps)
%!
%! ## likewise with normalized units
%! set (hf, "paperunits", "normalized");
%! fsz = [10.16 12.7]./psz;
%! pos = [([0.5 0.5] .- fsz/2) fsz];
%! assert (get (hf, "paperposition"), pos, eps)
%!
%! ## changing papertype updates paperposition
%! set (hf, "paperunits", "centimeters");
%! set (hf, "papertype", "a4");
%! psz = get (hf, "papersize");
%! fsz = [10.16 12.7];
%! pos = [(psz/2 .- fsz/2) fsz];
%! assert (get (hf, "paperposition"), pos, eps)
%!
%! ## lanscape updates paperposition
%! set (hf, "paperorientation", "landscape");
%! psz = get (hf, "papersize");
%! fsz = [10.16 12.7];
%! pos = [(psz/2 .- fsz/2) fsz];
%! assert (get (hf, "paperposition"), pos, eps)
%

Michael Godfrey <godfrey>
Sun 25 May 2014 03:57:58 PM UTC, comment #35:

Agreed but as I don't see the failure on my system (linux mint 14 x86_64) I don't see how to debug.

Michael, can you confirm that the failing assert is in the part of the test you cited? I am a bit puzzled as this part of the test shouldn't do more than set/get paperposition. At least, I could check that no unit conversion is made in this part of the test.

Pantxo Diribarne <pantxo>
Project Member
Fri 23 May 2014 10:26:29 PM UTC, comment #34:

Works for me: Fedora 20 x86_64

But, it would be useful to try to find why the result
is not exact as it is for you.

Michael Godfrey <godfrey>
Fri 23 May 2014 09:47:35 PM UTC, comment #33:

Michael, can you test the attached patch. I arbitrarily increased the tolerance to 20*eps.
I can't test my self as the original tests pass for me.

(file #31428)

Pantxo Diribarne <pantxo>
Project Member
Fri 23 May 2014 05:22:43 PM UTC, comment #32:

I was about to ask if this bug report couldn't be closed :-)

As there are multiple unit conversions, it is expected that some numerical errors may accumulate. I'll propose a patch to increase tolerance.

Pantxo Diribarne <pantxo>
Project Member
Fri 23 May 2014 12:16:02 PM UTC, comment #31:

The new test almost works: (maybe just allow a small tolerance?)

## back to manual mode
set (hf, "paperposition", pos+eps)
assert (get (hf, "paperpositionmode"), "manual")
assert (get (hf, "paperposition"), pos + eps)
unwind_protect_cleanup
close (hf);
end_unwind_protect
!!!!! test failed
ASSERT errors for: assert (get (hf, "paperposition"),pos)

Location | Observed | Expected | Reason
(2) 7.62 7.62 Abs err 8.8818e-16 exceeds tol 0
(4) 12.7 12.7 Abs err 1.7764e-15 exceeds tol 0

Michael Godfrey <godfrey>
Fri 23 May 2014 06:29:47 AM UTC, comment #30:

Thank you Ben.

Pantxo Diribarne <pantxo>
Project Member
Fri 23 May 2014 12:19:49 AM UTC, comment #29:

@Pantxo: I've pushed your change set

http://hg.savannah.gnu.org/hgweb/octave/rev/70ea5a2856fe

Ben Abbott <bpabbott>
Project Member
Thu 22 May 2014 07:12:33 PM UTC, comment #28:

I was thinking about including the pagesize as well, i.e. pagesize = paperposition(3:4).

However, while reading your reply it occurred to me that this is easy as

So, I agree. Your current patch does what I was looking for.

Ben Abbott <bpabbott>
Project Member
Thu 22 May 2014 06:08:14 PM UTC, comment #27:

Here is a summary of what I implemented:

  • the paperpositionmode (default = "manual"), that was unused, now works as all other *mode properties: when paperposition is set by the user, paperpositionmode becomes manual
  • when paperpositionmode is set "auto", the paperposition property is updated so that the figure is centered on the page and its size should be approximately the same as on screen.
  • when paperunits, papertype and position are changed, paperposition is updated.

Printing a figure that has the same size and aspect ratio as on screen should now be as simple as

Does it work for you?
I could check (see the %!test) that my implementation works also for landscape orientation but print.m doesn't handle it well. This should probably be discussed in bug #40259

Pantxo Diribarne <pantxo>
Project Member
Thu 22 May 2014 01:55:50 PM UTC, comment #26:

Opps. I thought I had looked for the change log and didn't find it.

I'm behind a firewall at the moment, so pushing will be delayed. I'll try to take care of that this evening.

Regarding "paperpositionmode", users occasionally desire print() to produce a result that is the same as seen on the screen. Could a new "paperpositionmode" be added that results in a file that is exactly the same size and aspect as that which is on the screen? If such is possible, maybe call it "screen"?

Ben Abbott <bpabbott>
Project Member
Thu 22 May 2014 05:40:46 AM UTC, comment #25:

If you are talking about the patch, there is already a ChangeLog included. I mistakingly produced it against gui-release branch so I attached an updated patch against default branch.

Now about the issues I have with GraphicsMagick, thanks for the hints, I'll try to contact fink maintainers.

(file #31413)

Pantxo Diribarne <pantxo>
Project Member
Thu 22 May 2014 12:33:53 AM UTC, comment #24:

Pantxo,

If you can include a ChangeLog, I can push the changeset.

Ben Abbott <bpabbott>
Project Member
Wed 21 May 2014 11:20:29 PM UTC, comment #23:

I used GraphicsMagick from Macports and also see segfaults. Using ImageMagick from Macports, there are no segfaults.

Alexander Hansen at Fink has been very responsive to changing Fink's Octave package. Perhaps you can email him and ask him to provide an ImageMagick version?

You could try a build yourself by modifying the info-file to use ImageMagick instead. I assume you just need to replace the line below,

+variant+
--with-magick=GraphicsMagick
-varatint-

With

+variant+
--with-magick=ImageMagick
-varatint-

Ben Abbott <bpabbott>
Project Member
Wed 21 May 2014 09:47:57 PM UTC, comment #22:

@Ben, I should have mentioned that the segfaults I see I likely due to my fragile mac build (some fink libraries, some other like GraphicsMagick are self compiled) so my comment about mac build was not relevant.

Pantxo Diribarne <pantxo>
Project Member
Wed 21 May 2014 08:57:20 PM UTC, comment #21:

I built the gui-release branch using Imagemagick and am able to run "make check" with not segfaults

Ben Abbott <bpabbott>
Project Member
Wed 21 May 2014 08:17:15 PM UTC, comment #20:

@Pantxo, are you using ImageMagick instead? Or just living with the segfaults?

Ben Abbott <bpabbott>
Project Member
Wed 21 May 2014 04:17:17 PM UTC, comment #19:

@Michael: see this tread [1], the data in the first comment show that back in 2004 they already had this bug.

@Ben: on linux, during make check I see only 1 failing test (in help.cc). On mac I have problems with GraphicsMagick that provoke segfaults, not due to octave.

[1] http://www.mathworks.com/matlabcentral/newsreader/view_thread/74190

Pantxo Diribarne <pantxo>
Project Member
Wed 21 May 2014 03:48:50 PM UTC, comment #18:

Looks like a regression/error in Matlab.
Lets not dfollow it.

Michael Godfrey <godfrey>
Wed 21 May 2014 01:39:38 PM UTC, comment #17:

hmm. I just tried "test graphics.cc", and all tests passed (./run-octave --no-gui)

I don't expect to find the segmentation fault is due to this patch.

Ben Abbott <bpabbott>
Project Member
Wed 21 May 2014 01:28:53 PM UTC, comment #16:

Quick comment.

When running "make check" I'm getting a segmentation fault with this #31407: update_paperposition.patch

I'll try to isolate the specific test when I can (my day is going to be very busy)

Ben Abbott <bpabbott>
Project Member
Wed 21 May 2014 06:21:44 AM UTC, comment #15:

I found the conversion ratio using the same method as Ben in R2012b.

Pantxo Diribarne <pantxo>
Project Member
Wed 21 May 2014 12:12:40 AM UTC, comment #14:

With R2013b I had to define the function unitsratio()
Notice that the output gives both the horizontal and vertical ratio (just in case they were different)

Ben Abbott <bpabbott>
Project Member
Tue 20 May 2014 11:32:34 PM UTC, comment #13:

The Matlab I use says:

>> unitsratio('cm','inch')


ans =

>> uni>> unitsratio('cm','inch')


ans =

2.5400

>> version


ans =

7.9.0.529 (R2009b)

>>


Where did you find 2.5381 ?

Michael Godfrey <godfrey>
Tue 20 May 2014 09:27:47 PM UTC, comment #12:

Hey,

I attached a patch for paperpositionmode.

The %!test in graphics.cc pass for me in octave. In matlab those tests don't pass: there are some small discrepencies that may be due to inch->centimeter conversions (in matlab: 1 in ~ 2.5381 cm ... strange).

(file #31407)

Pantxo Diribarne <pantxo>
Project Member
Mon 22 Oct 2012 12:08:23 PM UTC, comment #11:

I don't have much time to look at this now ... I just became a father 3 wks ago :-)

Hopefully, someone else can take this on.

Ben Abbott <bpabbott>
Project Member
Mon 22 Oct 2012 03:02:25 AM UTC, comment #10:

Alas, I haven't done much with the graphics code. I'm not sure who the expert is here, but jwe would probably know enough to point you in the right direction.

Rik <rik5>
Project Administrator
Sun 21 Oct 2012 01:38:06 AM UTC, comment #9:

Rik,

I've been looking at the c++ side, but so far have only gotten frustrated trying to figure out how the paperpositonmode updater should work. Do you have any insight into that?

Ben Abbott <bpabbott>
Project Member
Sat 20 Oct 2012 04:08:51 PM UTC, comment #8:

I just occurred to me that ML is likely using listeners to handle this. So I did a test to confirm.

This means my proposed patches are the wrong approach. Instead graphics.cc and graphics.h.in will need to be modified to properly handle the paperpositionmode and related properties.

Specifically we need the following updaters.

(1) If "position", "paperorientation", or "papersize" are modified and "paperpositionmode" == "auto" update "paperposition" so that the image is centered on the page.
(2) If "paperposition" is modified set "paperpositionmode" to "manual".

Anything else?

If those updaters are added, I think the current implementation for print.m will function correctly.

Ben Abbott <bpabbott>
Project Member
Sat 20 Oct 2012 03:06:41 PM UTC, comment #7:

Thanks Ben. The patch works for me for image formats like png, but ps and pdf outputs still appear scaled.

I've attached the two plots for reference.

(file #26805, file #26806)

Rik <rik5>
Project Administrator
Sat 20 Oct 2012 01:55:55 PM UTC, comment #6:

The diff below works properly for pdf/ps output

Ben Abbott <bpabbott>
Project Member
Sat 20 Oct 2012 03:20:59 AM UTC, comment #5:

I took a quick look. More testing (maybe some tests should be added to the script?) is needed, but this change below should fix this.

Ben Abbott <bpabbott>
Project Member
Tue 16 Oct 2012 11:44:46 PM UTC, comment #4:

The PaperPositionMode property, when set to auto, should use the plot size on screen for the print size. The image should be rendered centered on the page. Instead, printing uses the PaperPosition property values as if PaperPositionMode were set to manual.

Rik <rik5>
Project Administrator
Tue 16 Oct 2012 11:36:23 PM UTC, comment #3:

Agreed that this is bad design feature, but I also believe we need to keep Matlab compatability. I've found another problem. There is a PaperPositionMode property which defaults to manual. When it is set to 'auto', however, it is supposed to print the figure using the current on-screen dimensions. If this were working then you could have exactly what you want. I am going to re-title this report to reflect that bug.

Rik <rik5>
Project Administrator
Tue 16 Oct 2012 11:08:15 PM UTC, comment #2:

If you define a bug as working like matlab, this is a bug. Otherwise, I guess the fact that you have a window and by default it doesn't print is just a really bad feature.

Dov Kruger <dkruger>
Fri 12 Oct 2012 03:31:17 AM UTC, comment #1:

The size of the printed image is set using the PaperPosition property. This is not the same as the on-screen position set using the Position property. Try adjusting the PaperPosition property and verifying that the printed png image is sized differently.

Rik <rik5>
Project Administrator
Thu 11 Oct 2012 11:51:16 PM UTC, original submission:

set(gcf, 'Position', [800 300 500 600])
t=0:.1:10*pi;
plot(t, sin(t))
print(gcf, 'test.png', '-dpng');

Only the default window area is printed as a png, not the area appearing on the screen.

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #31458:  paperpos_fix_tol_v2.patch added by pantxo (4kB - application/x-download)
file #31428:  paperpos_fix_tol.patch added by pantxo (2kB - application/x-download)
file #31413:  update_paperposition_v2.patch added by pantxo (5kB - application/x-download)
file #31407:  update_paperposition.patch added by pantxo (6kB - application/x-download)
file #26805:  tst.png added by rik5 (4kB - image/png)
file #26806:  tst.ps added by rik5 (18kB - application/postscript)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by godfrey (Posted a comment)
  • -unavailable- added by pantxo (Updated the item)
  • -unavailable- added by bpabbott (Posted a comment)
  • -unavailable- added by dkruger (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 13 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 27 May 2014 07:42:53 PM UTCpantxoAttached File-=>Added paperpos_fix_tol_v2.patch, #31458
    Fri 23 May 2014 09:47:35 PM UTCpantxoAttached File-=>Added paperpos_fix_tol.patch, #31428
    Fri 23 May 2014 12:19:49 AM UTCbpabbottStatusConfirmed=>Ready For Test
    Thu 22 May 2014 05:40:46 AM UTCpantxoAttached File-=>Added update_paperposition_v2.patch, #31413
    Wed 21 May 2014 01:39:38 PM UTCbpabbottOperating SystemMicrosoft Windows=>Any
    Tue 20 May 2014 09:27:47 PM UTCpantxoAttached File-=>Added update_paperposition.patch, #31407
    Sat 20 Oct 2012 03:06:41 PM UTCrik5Attached File-=>Added tst.png, #26805
      Attached File-=>Added tst.ps, #26806
    Tue 16 Oct 2012 11:44:46 PM UTCrik5StatusWont Fix=>Confirmed
      Release3.6.2=>dev
      Summaryprint fails on sized windows?=>PaperPositionMode = 'auto' is ignored for printing
    Tue 16 Oct 2012 11:36:23 PM UTCrik5StatusNeed Info=>Wont Fix
    Fri 12 Oct 2012 03:31:17 AM UTCrik5StatusNone=>Need Info

    Back to the top


    Powered by Savane 3.1-cleanup