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

 
 

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

Submitter:  None
Submitted:  Thu 11 Oct 2012 11:51:16 PM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Dov Kruger Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * dev
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group 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>
Group 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>
Group Member
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>
Group Member
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>
Group 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>
Group Member
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>
Group 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>
Group Member
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>
Group 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:


%! hf = figure ("visible", "off", "paperpositionmode", "auto");
...


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


hf = figure ();
pos = get (hf, "paperposition");
set (hf, "paperunits", "centimeters")
set (hf, "paperunits", "inches")
assert (pos, get (hf, "paperposition"));

error: ASSERT errors for:  assert (pos,get (hf, "paperposition"))

  Location  |  Observed  |  Expected  |  Reason
    (2)          2.5          2.5        Abs err 4.4409e-16 exceeds tol 0

 
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>
Group 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>
Group Member
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>
Group 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>
Group Member
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>
Group 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>
Group 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>
Group Member
Fri 23 May 2014 06:29:47 AM UTC, comment #30: 

Thank you Ben.

Pantxo Diribarne <pantxo>
Group 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>
Group 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


set (gcf (), "paperpositionmode", "auto")
print -dpdfwrite test.pdf


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

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


hf = figure ();
plot(1:10);
set (hf, "paperpositionmode", "auto")
print toto.pdf


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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group Member
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>
Group 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>
Group 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>
Group Member
Wed 21 May 2014 12:12:40 AM UTC, comment #14: 

With R2013b I had to define the function unitsratio()

function r = unitsratio (u1, u2)
% USAGE: r = unitsratio (units1, units2)
% Returns the ratio of the values of a length with units1 and units2
  h = figure ('visible', 'off');
  set (h, 'units', u1)
  p1 = get (h, 'position');
  set (h, 'units', u2)
  p2 = get (h, 'position');
  r = p1(3:4) ./ p2(3:4);
end

Notice that the output gives both the horizontal and vertical ratio (just in case they were different)

unitsratio('centimeter', 'inches')
ans =
    2.5381    2.5381


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


>> close all
>> plot (rand (3))
>> get (gcf, 'paperposition')

ans =

    0.2500    2.5000    8.0000    6.0000

>> set (gcf, 'paperpositionmode', 'auto')
>> get (gcf, 'paperposition')

ans =

    1.1333    3.1667    6.2222    4.6667

>> set (gcf, 'paperpositionmode', 'manual')
>> get (gcf, 'paperposition')

ans =

    1.1333    3.1667    6.2222    4.6667


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


ezplot (@sin)
--Use mouse to make the plot a small square, on the order of 2"x2"
get (gcf, 'position')
ans =

   540   834   286   165
get (gcf, 'paperposition')
ans =

   0.25000   2.50000   8.00000   6.00000
set (gcf, 'paperpositionmode', 'auto')
print -dpng tst.png
print -dps  tst.ps


I've attached the two plots for reference.


file #26806)

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

The diff below works properly for pdf/ps output


diff --git a/scripts/plot/private/__print_parse_opts__.m b/scripts/plot/private/__print_parse_opts__.m
--- a/scripts/plot/private/__print_parse_opts__.m
+++ b/scripts/plot/private/__print_parse_opts__.m
@@ -239,11 +239,23 @@
               "pdf", "png", "tex", ...
               "eps", "ps", "ps", "pdf"};

+  if (any (strcmp (arg_st.devopt, {"ps", "ps2", "psc", "psc2", "pdf"})))
+    arg_st.formatted_for_printing = true;
+  endif
+
   if (isfigure (arg_st.figure))
     __graphics_toolkit__ = get (arg_st.figure, "__graphics_toolkit__");
+    paperpositionmode = get (arg_st.figure, "paperpositionmode");
+    if (strcmpi (paperpositionmode, "auto") && ! arg_st.formatted_for_printing)
+      arg_st.canvas_size = get (arg_st.figure, "position")(3:4);
+    endif
   else
     ## Allow tests when no figures are present.
     __graphics_toolkit__ = get (0, "defaultfigure__graphics_toolkit__");
+    paperpositionmode = get (0, "defaultfigurepaperpositionmode");
+    if (strcmpi (paperpositionmode, "auto") && ! arg_st.formatted_for_printing)
+      arg_st.canvas_size = get (0, "defaultfigureposition")(3:4);
+    endif
   endif

   if (strcmp (__graphics_toolkit__, "gnuplot")
@@ -289,10 +301,6 @@
     arg_st.send_to_printer = true;
   endif

-  if (any (strcmp (arg_st.devopt, {"ps", "ps2", "psc", "psc2", "pdf"})))
-    arg_st.formatted_for_printing = true;
-  endif
-
   aliases = gs_aliases ();
   if (any (strcmp (arg_st.devopt, fieldnames (aliases))))
     arg_st.devopt = aliases.(arg_st.devopt);


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


$ hg diff
diff --git a/scripts/plot/private/__print_parse_opts__.m b/scripts/plot/private/__print_parse_opts__.m
--- a/scripts/plot/private/__print_parse_opts__.m
+++ b/scripts/plot/private/__print_parse_opts__.m
@@ -241,9 +241,17 @@

   if (isfigure (arg_st.figure))
     __graphics_toolkit__ = get (arg_st.figure, "__graphics_toolkit__");
+    paperpositionmode = get (arg_st.figure, "paperpositionmode");
+    if (strcmpi (paperpositionmode, "auto"))
+      arg_st.canvas_size = get (arg_st.figure, "position")(3:4);
+    endif
   else
     ## Allow tests when no figures are present.
     __graphics_toolkit__ = get (0, "defaultfigure__graphics_toolkit__");
+    paperpositionmode = get (0, "defaultfigurepaperpositionmode");
+    if (strcmpi (paperpositionmode, "auto"))
+      arg_st.canvas_size = get (0, "defaultfigureposition")(3:4);
+    endif
   endif

   if (strcmp (__graphics_toolkit__, "gnuplot")


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

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

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    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 15 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-08-03 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2014-05-27 pantxo Attached File- Added paperpos_fix_tol_v2.patch, #31458
    2014-05-23 pantxo Attached File- Added paperpos_fix_tol.patch, #31428
    2014-05-23 bpabbott StatusConfirmed Ready For Test
    2014-05-22 pantxo Attached File- Added update_paperposition_v2.patch, #31413
    2014-05-21 bpabbott Operating SystemMicrosoft Windows Any
    2014-05-20 pantxo Attached File- Added update_paperposition.patch, #31407
    2012-10-20 rik5 Attached File- Added tst.png, #26805
        Attached File- Added tst.ps, #26806
    2012-10-16 rik5 StatusWont Fix Confirmed
        Release3.6.2 dev
        Summaryprint fails on sized windows? PaperPositionMode = 'auto' is ignored for printing
    2012-10-16 rik5 StatusNeed Info Wont Fix
    2012-10-12 rik5 StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code