> Tracing the problem a bit further: cairo_win32_surface_create() is being called
I don't recommend using cairo_win32_surface_create() for printing. Use the cairo_win32_printing_surface() in cairo 1.5.x instead.
cairo_win32_surface_create() is designed for displays. It requires the DC to support a destination bitmap that can be read. This is used to implement functionality that GDI does not support such as antialiasing and transparency. The problem is most printers don't support a destination bitmap so just about anything except text, images, and rectangles with integer coordinates is not going to print correctly. Even when the printer driver does support a destination bitmap we end spooling 100MB per page of raster data.
cairo_win32_printing_surface_create() works the same way the PostScript surface works. It uses the GDI API as much as possible since we don't need antialising at printer resolutions. For unsupported operations such as transparency, fallback images are used.
> Tracing the problem a bit further: cairo_win32_ surface_ create( ) is being called
I don't recommend using cairo_win32_ surface_ create( ) for printing. Use the cairo_win32_ printing_ surface( ) in cairo 1.5.x instead.
cairo_win32_ surface_ create( ) is designed for displays. It requires the DC to support a destination bitmap that can be read. This is used to implement functionality that GDI does not support such as antialiasing and transparency. The problem is most printers don't support a destination bitmap so just about anything except text, images, and rectangles with integer coordinates is not going to print correctly. Even when the printer driver does support a destination bitmap we end spooling 100MB per page of raster data.
cairo_win32_ printing_ surface_ create( ) works the same way the PostScript surface works. It uses the GDI API as much as possible since we don't need antialising at printer resolutions. For unsupported operations such as transparency, fallback images are used.