Bug 13657

Summary:	Black output with windows printing surface
Product:	cairo	Reporter:	mehmet yasar <myasar>
Component:	win32 backend	Assignee:	cairo-bugs mailing list <cairo-bugs>
Status:	RESOLVED FIXED	QA Contact:	cairo-bugs mailing list <cairo-bugs>
Severity:	normal
Priority:	medium	CC:	ajohnson
Version:	1.5.2
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	the original PDF the output rendered on the win32 printing surface and converted by PrimoPDF the output rendered by poppler on a pdf surface

Description mehmet yasar 2007-12-14 09:04:47 UTC

I'm using using poppler (version 0.6.2) to read pdf files and render them to a cairo surface (Tested with Cairo 1.5.4)

With the ps, svg or pdf surface the result is always correct.
With the printing surface, simple pdf files are printed correctly but complex ones give a completetly black output.

So I used a virtual PDF printer (PrimoPDF) to save the output, when I open the resulting pdf, the output seem to be covered with a black layer (under this layer the output is correct).

I can't provide a minimal testcase, but I can attach :
- the original PDF (from http://cworth.org/matplotlib/unicode_demo-cairo.pdf)
- the output rendered on the win32 printing surface and converted by PrimoPDF
- the output rendered on the pdf surface (I can also provide PS or SVG file)

I hope it will be enough to help Cairo developpers...

Comment 1 mehmet yasar 2007-12-14 09:05:35 UTC

Created attachment 13106 [details]
the original PDF

Comment 2 mehmet yasar 2007-12-14 09:07:03 UTC

Created attachment 13107 [details]
the output rendered on the win32 printing surface and converted by PrimoPDF

Comment 3 mehmet yasar 2007-12-14 09:07:54 UTC

Created attachment 13108 [details]
the output rendered by poppler on a pdf surface

Comment 4 Adrian Johnson 2008-01-11 03:57:23 UTC

From looking at the PrimoPDF generated PDF file I can see that all the text is output as a clip path followed by a fill. This is because the cairo backend of poppler only supports FreeType fonts. When Windows fonts are not used, win32-printing embeds text as paths. Currently this is done by setting a clip path and painting the source pattern as this will work for any pattern.

Looking at the PDF there are couple of places where the pattern (solid black) is painted without a clip path. I am assuming that these were glyphs with an empty path. Without a clip the entire page is painted with solid black.

I have pushed out a couple of patches to :

- don't clip and paint if the path is empty

http://gitweb.freedesktop.org/?p=cairo;a=commit;h=2574cc35b3478e7333bd4953e90a3edc5f7c4f16

- use fill instead of clip and paint for non Windows fonts

http://gitweb.freedesktop.org/?p=cairo;a=commit;h=7ef4caaf11379cb50a08520f729552553de60660

Can you test these to see if the problem is fixed.

Comment 5 mehmet yasar 2008-01-14 05:25:21 UTC

I confirm that your patches fixed all the printing problems.

Thanks

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.