[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