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
Forgot to say: Thanks for any comments! -Johan
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.
I was afraid someone would ask for C test case.. :(
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?)
Created attachment 39795 [details] Batch file to build the testcase with Inkscape's devlibs.
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.
Thanks for the fix, so this will be fixed in 1.11 ?
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.