bugGNU Octave - Bugs: bug #40259, Printing in landscape mode is...

 
 

bug #40259: Printing in landscape mode is clipped

Submitter:  Rik <rik5>
Submitted:  Sun 13 Oct 2013 06:01:03 PM UTC
   
 
Category:  Plotting 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

Fri 23 Sep 2016 07:17:31 PM UTC, comment #19: 

The patch passed my tests.  I pushed it here http://hg.savannah.gnu.org/hgweb/octave/rev/d084f11189f9.

Marking as fixed and closing report.

Rik <rik5>
Group administrator
Thu 22 Sep 2016 10:32:23 PM UTC, comment #18: 

Per Ben's suggestions in comment #15 I made Octave behave as ML: changing the orientation only swaps papersize, not paperposition.
Removing an additional unnecessary swap in _print_parse_opt_.m then fixes the issue, at least for the original exmaple. See attached patch.

(file #38590)

Pantxo Diribarne <pantxo>
Group Member
Thu 22 Sep 2016 12:09:38 AM UTC, comment #17: 

Just checked for this bug again and it is still present in 4.2.0-rc2.  Maybe this is a separate issue, but using the '-landscape' option to print also doesn't work.  The output remained in portrait mode.


graphics_toolkit fltk
plot (1:10, "o--r");
print -landscape tst.pdf



Rik <rik5>
Group administrator
Tue 10 Nov 2015 01:14:06 AM UTC, comment #16: 

Just verified on the development branch with dc2be2485968 and this bug is still present (11/9/2015).

Rik <rik5>
Group administrator
Sat 19 Jul 2014 03:53:50 PM UTC, comment #15: 

Opps. I forgot to explain why I don't like my prior patch.  Below is more context for the patch to _print_parse_opts_.m.  Note that transposing of the papersize is done twice.  At best, this is clumsy and confusing, but I suspect this points to a bug later in the code.


     papersize = papersizes (strcmp (papertypes, papertype), :);
   endif

+  ## Change default papersize if current paperorientation of figure is landscape
+  if (strcmpi (get (hfig,"paperorientation"), "landscape"))
+    papersize = papersize([2,1]);
+  endif
+
  if (strcmp (paperunits, "normalized"))
    paperposition = paperposition .* papersize([1,2,1,2]);
  else
    paperposition = convert2points (paperposition, paperunits);
  endif

  ## FIXME: This will be obsoleted by listeners for paper properties.
  ##        Papersize is tall when portrait,and wide when landscape.
  if ((papersize(1) > papersize(2) && strcmpi (paperorientation, "portrait"))
      || (papersize(1) < papersize(2) && strcmpi (paperorientation, "landscape")))
    papersize = papersize([2,1])
    paperposition = paperposition([2,1,4,3])
  endif


I addition, the remaining part of the function is


  if ((! strcmp (papertype, "<custom>")) && (strcmp (paperorientation, "portrait")))
    ## For portrait use the ghostscript name
    papersize = papertype;
    papersize(papersize=="-") = "";
    papersize = strrep (papersize, "us", "");
    switch (papersize)
      case "a"
        papersize = "letter";
      case {"b", "tabloid"}
        papersize = "11x17";
      case {"c", "d", "e"}
        papersize = strcat ("arch", papersize);
    endswitch
    if (strncmp (papersize, "arch", 4))
      papersize(end) = upper (papersize(end));
    endif
  endif

endfunction


I'd suggest this part be modified so that all cases are handled in the same way (to minimize code maintenance).

A good start would be to clean up the code with regards to papersize and paperorienetation.  Specifically the inconsistent behavior between Octave and Matlab seen below. Notice that changing the orientation flips the width/height of the papersize and paperposition in Octave, but only flip the width/height of the papersize in Matlab.  This may be the root cause of the bug (some/all of the code may be written expecting compatible behavior).


% MATLAB
get (gcf, 'paperorientation')

ans =

portrait

get (gcf, 'papersize'), get (gcf, 'paperposition')

ans =

    8.5000   11.0000

ans =

    0.2500    2.5000    8.0000    6.0000

set (gcf, 'paperorientation', 'landscape')
get (gcf, 'papersize'), get (gcf, 'paperposition')

ans =

   11.0000    8.5000

ans =

    0.2500    2.5000    8.0000    6.0000



# OCTAVE
 get (gcf, 'paperorientation')
ans = portrait
get (gcf, 'papersize'), get (gcf, 'paperposition')
ans =

    8.5000   11.0000

ans =

   0.25000   2.50000   8.00000   6.00000

set (gcf, 'paperorientation', 'landscape')
get (gcf, 'papersize'), get (gcf, 'paperposition')
ans =

   11.0000    8.5000

ans =

   2.50000   0.25000   6.00000   8.00000



Ben Abbott <bpabbott>
Group Member
Sat 19 Jul 2014 02:20:17 PM UTC, comment #14: 

Could you please write why do you think it's not a right thing? I may try to work on it, since proper functionality of this is quite of use in my situation.

As to print(). I'm not sure why the example I've posted might go wrong (NB, I've tried it with fltk only).

Before rendering and sending to GS figure size was correctly set according to its papersize. But since EPSCrop is false by default, figure's papersize is not taken into account by GS. And this is actually my question -- what GS uses instead of figure size when creating EPS file?

sergey plotnikov <nul0m>
Sat 19 Jul 2014 02:03:51 PM UTC, comment #13: 

I took another quick look at the code. I don't think my patch is the right thing to do.  I won't have time to work on this, so if someone is inspired/motivated please take a look. 

If there are any questions about how print() works, please ask (I wrote a lot of the code and should be to make time to answer questions).

Ben Abbott <bpabbott>
Group Member
Sat 19 Jul 2014 11:57:08 AM UTC, comment #12: 

Just an addition. If the change set Ben has offered is applied to Octave for Windows the charts are clipped for some reason.


figure;
for ix = 1 : 4
  subplot(2,2,ix);
  plot(sin(1:10),'linewidth',2);
end
orient('landscape');
print('-depsc', 'land_win.eps');


Result of that code is attached and can only be replicated on Windows, so I think it has something to do with ghostscript settings, which I'm not sure how to check. I merely tried different GS versions, but result was always the same.

I've tried 3.8.1-4 from http://mxeoctave.osuv.de/ and 4.1.0+ cross-compiled using MXE Octave (more details on my build is here).

(file #31749)

sergey plotnikov <nul0m>
Tue 08 Apr 2014 11:19:00 AM UTC, comment #11: 

I've played with that in Matlab and it's not so straightforward, i'd say. In the following example all three pdfs are landscape oriented but with a different figure position on a paper (files are attached):


>> figure
>> plot (rand (3,3))
>> get(gcf,'papertype')
ans =
usletter
>> set(gcf,'papersize',[11 8.5])
>> get(gcf,'papertype')
ans =
<custom>
>> get(gcf,'paperorientation')
ans =
portrait
>> print('-dpdf','land1.pdf')
set(gcf,'paperorientation','landscape')
>> get(gcf,'papersize')
ans =
    8.5000   11.0000
>> print('-dpdf','land2.pdf')
>> get(gcf,'paperposition')
ans =
    0.2500    2.5000    8.0000    6.0000
>> orient(gcf,'landscape')
>> get(gcf,'papersize')
ans =
    8.5000   11.0000
>> get(gcf,'paperposition')
ans =
    0.2500    0.2500    8.0000   10.5000
>> get(gcf,'paperorientation')
ans =
landscape
>> print('-dpdf','land3.pdf')


There are actually some behavior differences comparing to Octave:

  • once papersize is changed papertype should be set to <custom>
    • but paperorientation should stay the same
  • for a "custom" papertype -- changing paperorientation should swap papersize components irrespective to width/height ratio
  • print () should use papersize as it is for portrait oriented figures and swap papersize components (if needed) respecting width>height for lanscape oriented figures


But anyway, the change set you offered should be applied in case of standard papertypes since their papersize should be always set in line with paperorientation.


(file #31136, file #31137, file #31138)

sergey plotnikov <nul0m>
Wed 02 Apr 2014 04:57:48 PM UTC, comment #10: 

I'm not sure if Matlab always respects width>height for landscape. It is possible this only happens when the papertype is not "custom".

I don't have time to construct a set of tests to characterize what Matlab actually does, but can run tests for you or anyone else.

Ben Abbott <bpabbott>
Group Member
Wed 02 Apr 2014 04:39:44 PM UTC, comment #9: 

Completely agree, i had nothing against "width>height" approach, just paper size should take actual paper orientation into account.

sergey plotnikov <nul0m>
Wed 02 Apr 2014 04:29:19 PM UTC, comment #8: 

My understanding is that landscape implies that the paper width is larger than the height.  Thus, the code below should produce two identical pdf files.


close all
figure (1)
plot (rand (3))
set (gcf (), "papersize", [8.5, 11])
orient landscape
print -dpdf land1.pdf
set (gcf (), "papersize", [11, 8.5])
orient landscape
print -dpdf land2.pdf


I confirmed that Matlab follows this convention.

Perhaps the change set should include something like ...


if (strcmpi (get (hfig,"paperorientation"), "landscape"))
  papersize = sort (papersize, "descend");
else
  papersize = sort (papersize);
endif



Ben Abbott <bpabbott>
Group Member
Wed 02 Apr 2014 01:09:25 PM UTC, comment #7: 

I believe the problem comes from the line 588 (valid for cset 9597e00ed2dd) of _print_parse_opts_.m where "paperposition" is being changed wrongly since it has been already set in accordance with "paperorientation" when orient was run.

I'd offer the following patch to solve the issue.

(file #31101)

sergey plotnikov <nul0m>
Thu 17 Oct 2013 08:43:32 PM UTC, comment #6: 

I made orient compatible with Matlab in this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/26bd7d18a50c).  The bug report problem still remains that the printed output, even though all the figure properties are set correctly for landscape, is clipped.

I printed to postscript both tall and landscape oriented plots and the %%BoundingBox is being set correctly.  Maybe we aren't setting gl2ps up correctly.

Rik <rik5>
Group administrator
Thu 17 Oct 2013 06:12:32 PM UTC, comment #5: 

No.  The paperorientation is set to "portrait" independent of the defaultfigurepaperorientation property

Ben Abbott <bpabbott>
Group Member
Thu 17 Oct 2013 05:57:59 PM UTC, comment #4: 

Makes sense.  Does "portrait" return everything to default values?  For example, if you set the default paperorientation to be "landscape"  and then execute 'orient portrait' is the orientation restored to "landscape" or is it taken from input to the orient function?

If it really returns to the default then we might be clearer in Octave and introduce "default" as a keyword which is a synonym for "portrait".

Rik <rik5>
Group administrator
Thu 17 Oct 2013 04:57:19 PM UTC, comment #3: 

Rik, looks like Matlab is using the figure's default property values.  I ran the script below.


close all
plot (rand (3))

orient landscape
landscape_paperposition = get (gcf, 'paperposition')
landscape_papersize = get (gcf, 'papersize')

orient portrait
portrait_paperposition = get (gcf, 'paperposition')
portrait_papersize = get (gcf, 'papersize')

set (gcf, 'paperposition', portrait_paperposition/2)

orient portrait
portrait2_paperposition = get (gcf, 'paperposition')
portrait2_papersize = get (gcf, 'papersize')

try
  set (0, 'defaultfigurepaperposition', portrait_paperposition/2)
  orient portrait
  portrait3_paperposition = get (gcf, 'paperposition')
  portrait3_papersize = get (gcf, 'papersize')
catch
  set (0, 'defaultfigurepaperposition', portrait_paperposition)
end


and got


landscape_paperposition =    0.2500    0.2500   10.5000    8.0000

landscape_papersize =   11.0000    8.5000

portrait_paperposition =    0.2500    2.5000    8.0000    6.0000

portrait_papersize =    8.5000   11.0000

portrait2_paperposition =    0.2500    2.5000    8.0000    6.0000

portrait2_papersize =    8.5000   11.0000

portrait3_paperposition =    0.1250    1.2500    4.0000    3.0000

portrait3_papersize =    8.5000   11.0000


Ben Abbott <bpabbott>
Group Member
Thu 17 Oct 2013 04:16:15 PM UTC, comment #2: 

Ben, I pushed a changeset that looks for the landscape orientation and sets the 'paperposition' property to take up the entire page minus 0.25" margins (http://hg.savannah.gnu.org/hgweb/octave/rev/36917b3db6b2).

However, the plotted pdf is still not right.  Perhaps that indicates there is a problem with print.m

According to the Matlab documentation 'orient portrait' is supposed to get you back to the default.  Can you run the following check?


plot (rand (3))
orient landscape
get (gcf, 'paperposition')
orient portrait
get (gcf, 'paperposition')


If it returns the 'paperposition' to 8"x6" then we should do the same.

Rik <rik5>
Group administrator
Thu 17 Oct 2013 11:55:52 AM UTC, comment #1: 

I see some differences in how orient works.  Matlab is below.


plot (rand (3))
orient landscape
get (gcf, 'paperposition')

ans =    0.2500    0.2500   10.5000    8.0000


Octave's result is next.


plot (rand (3))
orient landscape
get (gcf (), 'paperposition')
ans =   2.50000   0.25000   6.00000   8.00000


The help for Matlab indicates that expanding the plot to fill the page is documented behavior.

orient LANDSCAPE causes subsequent PRINT operations from the current
    Figure window to generate output in full-page landscape orientation
    on the paper.

I can run tests if desired.

Ben Abbott <bpabbott>
Group Member
Sun 13 Oct 2013 06:01:03 PM UTC, original submission:  

A plot which is oriented in landscape mode seems to produce an output page which is landscape oriented, but the plot inside is still in portrait mode and clipped.

Sample code:


plot (1:10, ':or');
orient landscape
print -dpdf land.pdf


Attached is the resulting land.pdf plot.

Rik <rik5>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #38590:  landscape.patch added by pantxo (2KiB - text/x-diff)
file #31749:  land_win.eps added by nul0m (9KiB - image/x-eps)
file #31136:  land1.pdf added by nul0m (3KiB - application/pdf)
file #31137:  land2.pdf added by nul0m (3KiB - application/pdf)
file #31138:  land3.pdf added by nul0m (3KiB - application/pdf)
file #31101:  bug40259.patch added by nul0m (521B - text/x-patch)
file #29368:  land.pdf added by rik5 (3KiB - application/x-pdf)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by pantxo (Updated the item)
  • -email is unavailable- added by nul0m (Updated the item)
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by rik5 (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 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-09-23 rik5 StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2016-09-22 pantxo Attached File- Added landscape.patch, #38590
        StatusConfirmed Patch Submitted
    2014-07-19 nul0m Attached File- Added land_win.eps, #31749
    2014-04-08 nul0m Attached File- Added land1.pdf, #31136
        Attached File- Added land2.pdf, #31137
        Attached File- Added land3.pdf, #31138
    2014-04-02 nul0m Attached File- Added bug40259.patch, #31101
    2013-10-17 bpabbott StatusNone Confirmed
    2013-10-13 rik5 Attached File- Added land.pdf, #29368

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code