PDF output different than SVG source (cairo >= 1.11.2)

[revikati]

I have an SVG drawing made with Inkscape (source attached).
If I try to save it as a PDF from within Inkscape, the resulting image is different from the drawing (gradients missing etc.).
Looks like it is cairo related as the same problem happens when printing it to PDF from within inkscape (via cairo).

When saved as a PDF from Illustrator the resulting image is fine.

See screenshots:
* saved PDF with illustrator: http://i40.tinypic.com/mjo0p4.jpg
* saved PDF with inkscape: http://i40.tinypic.com/2h3rgwp.png
* printed to PDF from inkscape: http://i41.tinypic.com/dxxruc.png

I'm using cairo 1.12.1 from ppa:ricotz/testing, both inkscape stable and trunk affected.

[su_v (suv-lp)]

Confirmed - issue seems related to cairo version used by Inkscape: PDFs created with latest cairo versions (1.11.2, 1.12.0, git master) apparently incorrectly position/scale (?) gradients with transparent stops:

- not reproduced with Inkscape 0.48.2, 0.48.3.1 and 0.48+devel r11265 with cairo 1.10.2
- reproduced with Inkscape 0.48.2, 0.48.3.1 and 0.48+devel r11265 with cairo 1.11.2 and 1.12.0

[su_v (suv-lp)]

Correction:
- reproduced with Inkscape 0.48.2, 0.48.3.1 and 0.48+devel r11265 with cairo 1.11.2 and 1.12.0
+ reproduced with Inkscape 0.48.2, 0.48.3.1 and 0.48+devel r11265 with cairo 1.11.4 and 1.12.0

[su_v (suv-lp)]

Similar results with rsvg-convert from librsvg:

PDF ok: rsvg 2.34.x and cairo 1.10.0
PDF bad: rsvg 2.34.x, 2.36.1 and cairo 1.11.4, 1.12.0

To me this looks like an upstream issue in cairo (and not one specific
to Inkscape's own code).

[Adrian Johnson (ajohnson-redneon)]

I saw this bug mentioned on inkscape-devel. I've pushed a fix to cairo master. Unfortunately it didn't get fixed in 1.12.2 because no cairo bug was filed.

[ScislaC (scislac)]

@Adrian: That is great news. Regarding a bug not being filed against cairo, all of the bug reports against cairo that I've personally seen seem to be very technical. My main reason for not reporting upstream was due to not wanting to submit a subpar report. In the future, is it okay to file a bug report which we'll try to include as much information as we can and link back to the related bug in our tracker (where steps to reproduce and all of that will exist)?

[Adrian Johnson (ajohnson-redneon)]

It is better to file a subpar report that not say anything. If we don't know about a bug we can't fix it. As for the quality of bug reports - if you have a svg that reproduces the bug that is good enough.

[su_v (suv-lp)]

> I've pushed a fix to cairo master.

Fix confirmed with cairo git master (f228769dfe5a8b5d73c49a41e95e31ed73a77fb3) on OS X 10.7.4,
testing Inkscape 0.48.3.1 and current trunk (r11469) with DYLD_LIBRARY_PATH set to load cairo 1.12.3 (git master) instead of current stable 1.12.2.

Setting bug status to 'Triaged' (can be closed as 'Invalid' for Inkscape once the fix is available in a released stable version of cairo).

[jazzynico (jazzynico)]

Doesn't seem to affect Windows builds. Not reproduced on XP with 0.48.3.1 and trunk revision 11859, cairo 1.11.2.

[Ernst-gumpinger-w (ernst-gumpinger-w)]

Reproduced under debian-wheezy, using Inkscape version 0.48.3.1 r9886 and libcairo2 version 1.12.2-3

This bug is not reproduced under Windows XP with inkscape versions 0.48.2 r9819 and 0.48.4 r9939.

It seems to be related to gradients with transparent stops, so a possible work-around is changing the transparent stop to the colour of the layer underneath the gradient stop.

[su_v (suv-lp)]

Closing for project 'Inkscape' - upstream bug in certain older cairo versions (1.11.4 - 1.12.2).

None of the current pre-compiled packages for Inkscape 0.91 provided by inkscape.org does include an affected version of cairo:
- 32bit Windows: cairo 1.11.2 (not affected)
- 64bit Windows: cairo 1.14.1 (bug fixed)
- 32bit, 64bit Mac OS X: cairo 1.14.0 (bug fixed)