Bug 31140

Summary:	PDF export stroke color wrong for black lines
Product:	cairo	Reporter:	Johan Engelen <goejendaagh>
Component:	pdf backend	Assignee:	Adrian Johnson <ajohnson>
Status:	RESOLVED FIXED	QA Contact:	cairo-bugs mailing list <cairo-bugs>
Severity:	normal
Priority:	medium
Version:	1.10.1
Hardware:	x86 (IA32)
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	Test case, showing the bug. Batch file to build the testcase with Inkscape's devlibs.

Description Johan Engelen 2010-10-26 12:15:20 UTC

The stroke color of a line with black color (rgb=000000) is wrong in the PDF export; instead of black, it is the color of the last stroked path.

First I export a path with these fill/stroke details
<path style="fill:none;stroke:#097101;stroke-width:2;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;stroke-miterlimit:4;stroke-dasharray:none" />
which is a green line.

Then an object with fill:
   <path style="fill:url(#linearGradient6712);fill-opacity:1;stroke:black;stroke-width:0.6;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" /> 

Then a black stroked path:
   <path style="fill:none;stroke:#000000;stroke-width:0.56444448000000003;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />

The stroke color of this last path is #097101 instead of black.
The color is correct when changing any of these:
- change fill of 2nd object to a solid color (instead of gradient)
- change stroke color of 2nd object to something other than black
- change stroke color of last path to something other than black
- change stroke-opacity of 2nd object to e.g. 0.9

Perhaps cairo ignores the black color, thinking it is default for paths?

See Inkscape bug: https://bugs.launchpad.net/inkscape/+bug/665628

Comment 1 Johan Engelen 2010-10-26 12:16:44 UTC

Forgot to say: Thanks for any comments!
-Johan

Comment 2 Andrea Canciani 2010-10-26 12:20:04 UTC

Could you provide a C test case reproducing the issue?
It would help to exclude that the problem is in how inkscape uses cairo and it could also be added to the test suite.

Comment 3 Johan Engelen 2010-10-26 12:23:38 UTC

I was afraid someone would ask for C test case.. :(

Comment 4 Johan Engelen 2010-10-26 13:09:37 UTC

Created attachment 39794 [details]
Test case, showing the bug.

Here code that reproduces the bug. Confirming it is not an Inkscape bug, but Cairo. (or bad use of cairo?)

Comment 5 Johan Engelen 2010-10-26 13:10:23 UTC

Created attachment 39795 [details]
Batch file to build the testcase with Inkscape's devlibs.

Comment 6 Adrian Johnson 2010-10-28 04:02:19 UTC

Fixed with this commit

http://cgit.freedesktop.org/cairo/commit/?id=e23bcfd4300870034f07b1ecd1bb4d2ac95d9785

As an optimisation cairo remembers the currently selected color to avoid emitting the set color operator before each drawing operation if the color is the same as the previous drawing operation. The problem here is cairo remembers the set black used for the 2nd stroke however the 2nd stroke and fill occurs inside a save/restore pair. After the restore the current pdf color reverts to the yellow of the first stroke. Fixed by making cairo emit the set color operator after a restore operator.

Comment 7 Johan Engelen 2010-10-28 15:19:02 UTC

Thanks for the fix, so this will be fixed in 1.11 ?

Comment 8 Adrian Johnson 2010-10-29 00:23:14 UTC

It has been fixed in the git master and 1.10 branch so it will appear in the 1.10.2 (stable) and 1.11.2 (development snapshot) releases.

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.