Bug 56525

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.

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?

(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

(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

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

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

GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=687273

Thanks for your help, Adrian.