Bug 31140 - PDF export stroke color wrong for black lines
Summary: PDF export stroke color wrong for black lines
Alias: None
Product: cairo
Classification: Unclassified
Component: pdf backend (show other bugs)
Version: 1.10.1
Hardware: x86 (IA32) All
: medium normal
Assignee: Adrian Johnson
QA Contact: cairo-bugs mailing list
Depends on:
Reported: 2010-10-26 12:15 UTC by Johan Engelen
Modified: 2010-10-29 00:23 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Test case, showing the bug. (1.33 KB, text/plain)
2010-10-26 13:09 UTC, Johan Engelen
Batch file to build the testcase with Inkscape's devlibs. (3.55 KB, application/octet-stream)
2010-10-26 13:10 UTC, Johan Engelen

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!
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


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.