Bug 16937 - Win32 printing backend draws black background behind vector graphics
Summary: Win32 printing backend draws black background behind vector graphics
Status: RESOLVED FIXED
Alias: None
Product: cairo
Classification: Unclassified
Component: win32 backend (show other bugs)
Version: 1.6.4
Hardware: Other All
: medium major
Assignee: cairo-bugs mailing list
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-01 02:22 UTC by Dov Grobgeld
Modified: 2008-10-13 04:43 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Image illustrating bug in the win32 printing backend. (108.96 KB, image/png)
2008-08-01 02:22 UTC, Dov Grobgeld
Details

Description Dov Grobgeld 2008-08-01 02:22:03 UTC
Created attachment 18060 [details]
Image illustrating bug in the win32 printing backend.

An application of mine (giv) draws an image and vector graphics on top of the image. Lately I have added printing support, which works fine under Linux through the pdf backend. But the same cairo commands causes the wrong output through the win32 printing backend. The series of commands are roughly:

* Draw an image through 

    cairo_set_source_surface()
    cairo_paint()

* Draw vector graphics through

    cairo_move_to()
    cairo_line_to()
    cairo_stroke()

The resulting rendering is attached. On windows the image was generated through the CutePDF backend, but the result was verified to be the same through other win32 printing backends.
Comment 1 Zac Luzader 2008-08-06 18:12:21 UTC
I can confirm this in pycairo/pygtk on winxp:
gtk (2, 12, 10)
pygtk (2, 12, 1)
cairo 1.6.4
pycairo (1, 4, 12)

I can also confirm that bug occurs when using a virtual pdf printer (pdfcreator), as well as when using a real printer.

A black rectangle is painted behind vector graphics, the rectangle is the same as the path's bounding box. For example:

context.move_to(0,0)
context.line_to(100,100)
context.stroke()

produces a black square, 100x100, instead of a line.

I've noticed some other clues:

* You need not draw over an image to trigger the bug. Attempting to draw on blankness will trigger it too.
* Notably, the show_text function is not effected. i.e. context.show_text("blah"); context.fill() works as expected.
* Using panocairo, however does trigger the bug. Presumably pangocairo uses normal paths instead of show_text or show_glyphs.
Comment 2 Adrian Johnson 2008-10-11 01:55:18 UTC
I am unable to reproduce this. If you can provide a simple test case it would assist in further investigating this problem.
Comment 3 Zac Luzader 2008-10-12 14:02:48 UTC
Nor can I since upgrading to:
gtk (2, 14, 2)
pygtk (2, 12, 1)

I no longer get this bug.

print "cairo",cairo.cairo_version_string()
print "cairo info",cairo.version_info

still gives:

cairo 1.6.4
cairo info (1, 4, 12)

Looks like GTK's win32 printing was seriously overhauled in 2.13:
http://bugzilla.gnome.org/show_bug.cgi?id=488833
So that's probably where the bug was. I had a feeling I was reporting against the wrong project after hitting Commit. Sorry.
Comment 4 Dov Grobgeld 2008-10-13 04:43:51 UTC
I just updated to the last version of cairo for win32 and the problem indeed has been solved! Thanks a lot. Closing the bug.


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.