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 687273 - default Windows print margins do not match Linux print margins
default Windows print margins do not match Linux print margins
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Printing
2.24.x
Other Windows
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2012-10-31 15:31 UTC by Michael Cronenworth
Modified: 2018-02-10 03:20 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
test case (1.65 KB, text/plain)
2012-10-31 15:31 UTC, Michael Cronenworth 		Details

Description Michael Cronenworth 2012-10-31 15:31:00 UTC 
Created attachment 227733 [details]
test case

Some history: https://bugs.freedesktop.org/show_bug.cgi?id=56525
The bug includes a test case that I will also attach here.

In summary:
If I print text to a printer in Linux with coordinates (0,0), the text is fully visible at the top left of the printed page. When I use the same code to print in Windows the text is shift up, and too high for the printer to print so the text is cut in half.

If I set the top margin with
  gtk_page_setup_set_top_margin( setup, 0.3, GTK_UNIT_INCH ); 
the resulting output in a Windows build matches the Linux build that does not call that function. If I call the function in Linux the printed output is lower on the page than the Windows output.

Linux:
Fedora 17 x86_64
GTK 2.24.13 / Cairo 1.10.2 / Pango 1.30.0

Windows:
Windows 7 x86_64
GTK 2.24.13 / Cairo 1.12.6 / Pango 1.30.0

Printer:
Lexmark T640
Comment 1 Matthias Clasen 2018-02-10 03:20:52 UTC 
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and
still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue
for it.