Bug 56525 - Printer output inconsistent, shifted up in Windows
Summary: Printer output inconsistent, shifted up in Windows
Status: RESOLVED NOTOURBUG
Alias: None
Product: cairo
Classification: Unclassified
Component: win32 backend (show other bugs)
Version: 1.12.6
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: cairo-bugs mailing list
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-29 14:54 UTC by Michael Cronenworth
Modified: 2012-10-31 15:33 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
test case (1.65 KB, text/plain)
2012-10-29 14:54 UTC, Michael Cronenworth
Details

Description Michael Cronenworth 2012-10-29 14:54:45 UTC
Created attachment 69233 [details]
test case

Under Linux and Windows, when I print to PDF or my custom print preview window my text aligns the way I think it should. When I print to a printer in Linux the output matches identically with the PDF or print preview.

When I print to the same printer in Windows my text is printed higher than what is shown on the PDF or print preview window. It prints higher by about 2mm, but this is enough to cut Arial 10pt text in half if printed at the very top of the page on a Lexmark laser printer.

If I print the PDF that is generated by Cairo in Windows the printer output is identical to that of the PDF and the same that I get from printing in Linux.

I have attached a simple test case that replicates the problem. If you run in it Linux it should print the full word "Test Text" at the top left of the paper. Under Windows the word will be cut in half.

Linux:
Fedora 17 x86_64
GTK 2.24.13 / Cairo 1.10.2

Windows:
Windows 7 x86_64
GTK 2.24.13 / Cairo 1.10.2 & 1.12.6

Printer:
Lexmark T640
Comment 1 Adrian Johnson 2012-10-29 21:56:37 UTC
I suspect this is more likely to be a gtk bug. The cairo windows printing surface just draws onto the HDC supplied to it without any translation of coordinates.

This is the test code I used when working on hard margins for gtk:
http://people.freedesktop.org/~ajohnson/print.c

You can try it to see that the hard margins are correct and the rectangle is visible. The rectangle should disappear if you expand it to be just outside the hard margins.
Comment 2 Michael Cronenworth 2012-10-30 13:29:08 UTC
I took your test without modifying it.

Linux: Prints "abcde" with no rectangle border.

Windows: Prints "abcde" in slightly smaller font with a rectangle border around the page.

Should I move this bug to GTK's bugzilla?
Comment 3 Michael Cronenworth 2012-10-30 13:32:04 UTC
(In reply to comment #2)
> I took your test without modifying it.
> 
> Linux: Prints "abcde" with no rectangle border.
> 
> Windows: Prints "abcde" in slightly smaller font with a rectangle border
> around the page.

Linux console:
$ ./printtest 

(printtest:16738): GLib-GObject-WARNING **: invalid cast from `GtkButton' to `GtkWindow'

(printtest:16738): GLib-GObject-WARNING **: g_object_new_valist: invalid object type `GtkButton' for value type `GtkWindow'
Context width: 611.999983  height: 791.999983
Hard margins: top: 0.000000  left: 0.000000  right: 0.000000  bottom: 0.000000

Windows console:
S:\>printtest1

(printtest1.exe:2228): GLib-GObject-WARNING **: invalid cast from `GtkButton' to
 `GtkWindow'
Context width: 611.999983  height: 791.999983
Hard margins: top: 18.000000  left: 18.000000  right: 18.000000  bottom: 18.0000
00
Comment 4 Adrian Johnson 2012-10-31 12:08:44 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > I took your test without modifying it.
> > 
> > Linux: Prints "abcde" with no rectangle border.

The missing rectangle is due to the 0 margins.

> > 
> > Windows: Prints "abcde" in slightly smaller font with a rectangle border
> > around the page.

Not sure why it would be smaller. It is in the same position?

> 
> Linux console:
> $ ./printtest 
> 
> (printtest:16738): GLib-GObject-WARNING **: invalid cast from `GtkButton' to
> `GtkWindow'
> 
> (printtest:16738): GLib-GObject-WARNING **: g_object_new_valist: invalid
> object type `GtkButton' for value type `GtkWindow'
> Context width: 611.999983  height: 791.999983
> Hard margins: top: 0.000000  left: 0.000000  right: 0.000000  bottom:
> 0.000000

I expect the 0 margins are this bug:
https://bugzilla.gnome.org/show_bug.cgi?id=686109

> 
> Windows console:
> S:\>printtest1
> 
> (printtest1.exe:2228): GLib-GObject-WARNING **: invalid cast from
> `GtkButton' to
>  `GtkWindow'
> Context width: 611.999983  height: 791.999983
> Hard margins: top: 18.000000  left: 18.000000  right: 18.000000  bottom:
> 18.0000
> 00
Comment 5 Adrian Johnson 2012-10-31 12:31:37 UTC
(In reply to comment #2)
> Should I move this bug to GTK's bugzilla?

I have not seen any evidence that cairo is at fault.

It would help if you could do more tests to isolate the cause. Your test case is using three different libraries that could affect the printout - cairo, gtk, and pango.

I don't currently have a gtk development environment on windows set up so all I can do is offer some suggestions.

Try using cairo by itself to create pdf and postscript files with a rectangle. Print them out and use a ruler to check the size and position is correct. Cairo uses points (1/72 inch) for units. You printer accepts pdf and ps so you can bypass cups and print directly with lpr -l. CUPS may do scaling depending on how it is configured so it is important to print directly to the printer.

Try printing the pdf from windows and check the dimensions. If using Adobe Reader ensure that the scale option in the print dialog is set to None.

Convert the stand along cairo program to use gtkprint and check the results.

If the rectangle size and position is correct you could repeat the tests with some text. I suggest installing the same font on Linux and Windows for the test.
Comment 6 Michael Cronenworth 2012-10-31 15:21:09 UTC
(In reply to comment #5)
> (In reply to comment #2)
> > Should I move this bug to GTK's bugzilla?
> 
> I have not seen any evidence that cairo is at fault.

I will agree with you now. The PDF/screen output is consistent. The placement of objects on the printed page is consistent. The problem lies with GTK.

As I cannot wait for a fix (commercial app) I found a temporary workaround in setting the top margin to "0.3 inches" for Windows builds in the "request-page-setup" GTK signal. This matches the Linux build (with no top margin set) printer output. If I set the same top margin for the Linux build the Linux build prints slightly lower than the Windows build. If I set "0.25", which should be the default to begin with, I get the first line of text chopped in half on Windows, and correct printing on Linux.
Comment 7 Michael Cronenworth 2012-10-31 15:33:00 UTC
GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=687273

Thanks for your help, Adrian.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.