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

 
 

bug #40259: Printing in landscape mode is clipped

Submitted by:  Rik <rik5>
Submitted on:  Sun 13 Oct 2013 06:01:03 PM UTC  
 
Category: PlottingSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: ConfirmedAssigned to: None
Originator Name: Open/Closed: Open
Release: devOperating System: GNU/Linux

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)

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.

I addition, the remaining part of the function is

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

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

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

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

I confirmed that Matlab follows this convention.

Perhaps the change set should include something like ...

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

and got

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

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

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

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

Octave's result is next.

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>
Project 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:

Attached is the resulting land.pdf plot.

Rik <rik5>
Project Administrator

 

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

Attach File(s):
   
   
Comment:
   

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

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by nul0m (Updated the item)
  • -unavailable- added by bpabbott (Posted a comment)
  • -unavailable- added by rik5 (Submitted the item)
  •  

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

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 19 Jul 2014 11:57:08 AM UTCnul0mAttached File-=>Added land_win.eps, #31749
    Tue 08 Apr 2014 11:19:00 AM UTCnul0mAttached File-=>Added land1.pdf, #31136
      Attached File-=>Added land2.pdf, #31137
      Attached File-=>Added land3.pdf, #31138
    Wed 02 Apr 2014 01:09:25 PM UTCnul0mAttached File-=>Added bug40259.patch, #31101
    Thu 17 Oct 2013 11:55:52 AM UTCbpabbottStatusNone=>Confirmed
    Sun 13 Oct 2013 06:01:03 PM UTCrik5Attached File-=>Added land.pdf, #29368

    Back to the top


    Powered by Savane 3.1-cleanup