[cairo] Win32 printing

Adrian Johnson ajohnson at redneon.com
Tue Jun 19 07:21:00 PDT 2007


The windows backend has two problems when used with a printer device 
context:
 - It can generate huge bitmapped output that takes several minutes per 
page to print.
 - For the printer drivers I have tested, reading image data back from 
the printer DC is not supported.
   This means that transparency and other operations that require 
reading from the destination surface
  do not produce the correct output.

For example testing with the HP 4550 PostScript print driver:

- Printing a transparent rectangle over some text results in an opaque 
rectangle without any of the text under the rectangle visible.

- Drawing a gradient that covers the page results in a 150MB image in 
the PostScript output even though PS Level 3 supports gradients.

- Printing the 80KB romedalen.png image from the test suite to a 200 by 
200 point square results in 10MB of PostScript output as the
  image is embedded at the device resolution instead of the image 
resolution.

- Use of operators other than CAIRO_OPERATOR_OVER produces incorrect 
results.

See also http://bugs.freedesktop.org/show_bug.cgi?id=9064


I have written test boilerplate for testing win32 printing to a color 
PostScript printer.
   
http://gitweb.freedesktop.org/?p=users/ajohnson/cairo.git;a=commit;h=4ba6227a2f26ac61427706167425b19ad8b6554f 

This code requires a color PostScript Windows printer driver to be 
installed and set as the default printer. It prints to the default printer,
saves the PS output and uses ghostscript to create the png image.


I have also started work on extending the win32 surface to fix these 
problems:
  
http://gitweb.freedesktop.org/?p=users/ajohnson/cairo.git;a=commit;h=930d41687ce16798bf992e44d66cde4a67c89163

The changes involve:
  - In the win32-surface constructor if the device context is not a 
display the surface is created as a paginated surface.
    This allows to the paginated, meta, and analysis surfaces to be used 
to identify and handle the unsupported printer
    operations such as transparency as image fallbacks.

  - Implement the _fill, _stroke, _paint, _show_glyphs, and 
_intersect_clip_path backend operations. Where possible
   the GDI functions that result in vector based PostScript output are 
used. The existing show_glyphs function is used
   when printing solid patterns.

Testing with these changes appears to fix both issues. The PostScript 
out is small and prints quickly. Images are embedded
at their native resolution. Linear gradients are natively supported on 
PS Level 3 printers. All transparency and cairo operators
produce correct output.

I have been unable to get the cairo tests to pass due to the differences 
between the win32 printer device space and the device space
assumed by the tests. On windows the printer device space is one unit == 
1 printer dot (eg 1/600" for the HP 4550) with the origin
at the top left of the printable area. The cairo tests all assume that 
printer backends have a device space of 1 unit == 1/72".



More information about the cairo mailing list