After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 551356 - Incorrect printing in landscape mode
Incorrect printing in landscape mode
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Printing
2.21.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2008-09-08 11:31 UTC by Maxim Levitsky
Modified: 2015-02-04 17:38 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22


Attachments
rotate hard margins according to page orientation (2.35 KB, patch)
2010-12-28 10:56 UTC, Adrian Johnson
none Details | Review

Description Maxim Levitsky 2008-09-08 11:31:03 UTC
Please describe the problem:
Each paper type has some margins. They are supposed to tell that printer can't print beyond those margins.

I want to print photos on 4x6 paper in landscape mode but this paper type has wide margin at bottom of paper which is fine, but as soon as I select the 'landscape' mode the margin moves at side of paper, or in other words rotates with image.

Steps to reproduce:
1. open a photo
2. select 4x6 page size at page setup
3. open print preview


Actual results:
You see large white space on the right of image

Expected results:
Image should fill all page

Does this happen every time?
Yes (but it can depend a bit on printer since page types are printer dependent).
But you can define custom page type with margin at bottom, to emulate this.

Other information:
Comment 1 Maxim Levitsky 2008-09-08 11:32:33 UTC
Forgot to tell that you need to select landscape mode as well in stepes to reproduce
Comment 2 Felix Riemann 2008-09-29 10:43:46 UTC
So, the problem is that the borders are set as if you would actually insert the paper into your printer landscape oriented, right?

Hmm, I need to check if that is specific to EOG's printing or if it is a problem with GtkPrint.
Comment 3 Maxim Levitsky 2008-09-29 15:14:38 UTC
More or less yes.

If you take photo paper and look at it in exctly same was as normal paper, then it will have wide border at bottom.

But when I print on paper in landscape mode, then if you look at paper in exactly the same way, you see that border in on left or right of page (don't remember exactly, depends on "reverse landscape".


Probably this is a gtk-print bug, as gimp shows same bug.

While we are at it, could you make eog save its page setup options?
Or al least add a button to print dialog to launch page setup options like gimp does. It is very annoying.

I would be very happy to see both dialogs merged, btw.

See:

http://bugzilla.gnome.org/show_bug.cgi?id=551409
http://bugzilla.gnome.org/show_bug.cgi?id=551357
Comment 4 Maxim Levitsky 2009-09-18 21:48:12 UTC
This is still not fixed

Paper margins still aren't rotated with paper orentation
Comment 5 Felix Riemann 2010-08-21 10:37:09 UTC
I am not so sure anymore if the hard paper margins are actually an error. The margins are a printer-specific value (aren't they?) independent of the orientation of the inserted paper. And thus the current bahaviour appears correct to me.

Anyways, as GIMP bahaves identical this is probably related to GtkPrint. Re-assigning for confirmation.
Comment 6 Adrian Johnson 2010-12-28 10:56:00 UTC
Created attachment 177127 [details] [review]
rotate hard margins according to page orientation

This is a bug in gtk printing. The hard margins are a physical limitation of the printer. So for example if a printer has the hard margins:
  top:    0.5"
  left:   0.25"
  right:  0.25"
  bottom: 1"
  
and the print context has landscape orientation, the hard margins returned by the print context should be:
  top:    0.25"
  left:   1"
  right:  0.5"
  bottom: 0.25"

Attached is a patch to fix this.
Comment 7 Carlos Garcia Campos 2015-01-28 10:08:12 UTC
So, is this a duplicate of bug #671895?
Comment 8 Marek Kašík 2015-02-04 17:38:03 UTC
This bug is actually related to these two commits:

https://git.gnome.org/browse/gtk+/commit/?id=779faafa22af99614bb0f6a5526b4d901a7b095f

https://git.gnome.org/browse/gtk+/commit/?id=9ac9769f360df4d63b4f6e7cbb572092e263c5ea

These are now in master and will be part of Gtk+ 3.16. They fix the problem for me.