transparency lost in pdf export of groups with clip-path= property

Please attach a sample SVG file and the PDF file exported on your system to allow further investigation with different versions of Inkscape and cairo.

Which OS/platoform do you use?

I'm using Linux x86-64 (OpenSuse 13.1)

I have added four files:

orig.svg and the exported orig.pdf ( note the clip-path statement in the group with id g4295)
where the wrong export occured

orignew.svg and the corresponding orignew.pdf, what shows the correct export

thank's for consideration.

Note: the SVG file 'orig.svg' in the ZIP archive was edited/resaved in
Inkscape, and is not the original original SVG file as created by
Mathematica 8.0. AFAICT it doesn't make a difference though - the "bug"
seems to be in cairo, not Inkscape (see attached PDF files exported with
0.48.2, 0.48.3.1, 0.48.4 and 0.48.x r9990, using different cairo
versions: independent of Inkscape version, all exports with cairo
1.12.12 and 1.12.16 ingore the opacity of the clipped path as described).

On 2013-12-09 11:26 +0100, su_v wrote:
> independent of Inkscape version, all exports with cairo 1.12.12 and
> 1.12.16 ingore the opacity of the clipped path as described).

Correction (wrong cairo version cited):
independent of Inkscape version, all exports with cairo 1.12.14 and
1.12.16 ingore the opacity of the clipped path as described.

(I also got that one cairo version wrong in the file name
(s/1.12.12/1.12.14/), but file info will report the correct PDF version).

On 2013-12-05 20:19 +0100, Joachim Hein wrote:
> The same could be achieved by importing the svg into inkscape, then
> degrouping all grouped objects and group them again. Inkscape then
> will place the <clipPath outside the groups and is now able to do the
> export correctly. This may also an svg inconsistency.

Ungrouping is simply another way to get rid of the clip-path applied to the top-level group (the 'clip-path' attribute is not retained when ungrouping and regrouping). Any chance you could attach the original SVG file created by Mathematica 8.0, too (without opening and resaving it in Inkscape first)?

Sample reduced test case attached, created entirely in Inkscape.
(The trigger is not related to where the definition of the clip-path is stored in the SVG source)

PDF export with Inkscape 0.48.4 using cairo 1.12.2 (correct reduced transparency of the object inside the clipped group)

PDF export with Inkscape 0.48.4 using cairo 1.12.16 (reduced opacity of the object inside the clipped group is ignored)

JFTR: while this issue cannot be tested with current trunk >= 12544 (due to bug #1256449), it can be reproduced with r12543 (cairo 1.12.2: correct reduced opacity of object inside clipped group, cairo 1.12.16: reduced opacity of object inside clipped group is ignored)

If it is finally a cairo bug, what is the way on installing inkscape with an older cairo version?

Yes, sure I can add an original export from Mathematica, nevertheless it is not exactly the same because I used inkscape to delete some objects in order to reduce complexity of the svg file and because I also noticed that the behavior hasn't changed. But yes here is a comparable Mathematica 8.0 svg export.

> But yes here is a comparable Mathematica 8.0 svg export.

The file attached in comment #10 has no applied clip-paths - it will not trigger the reported issue. It doesn't really matter though: the problem can be reproduced with files created entirely in Inkscape (see comments 6-8).

> If it is finally a cairo bug, what is the way on installing inkscape with an older cairo version?

It has yet to be determined where exactly the bug is located (my comments are part of the bug triage process (to provide additional information for the devs), and not meant as instructions or recommendations to the reporter how to downgrade a shared and widely used library like cairo on Linux): rsvg-convert from librsvg for example does not expose the same issue, independent of which cairo version it uses.

I'm sorry, I forgot that in the creation process all clip-paths are removed, but as it is not needed anymore, I expect that I do not need to do anything.

Nevertheless I'm not expected to downgrade cairo, I did a try and downgraded the libcairo package that was available for my linux distribution to version 1.12.8. and interestingly: This does not help either! What might be a useful information to the devs because this excludes a dependence from the cairo libraries (or library versions) in accordance with the observations that the behavior is not seen with rsvg-convert.

Unfortunately, rsvg-convert does not give me the option to extract text for further latex-processing. That' why it is no option for me. Meanwhile, I also have figures that require the clip-path (Mathematica will unfortunately plot functions sometimes also outside the visible region), so I have a strong interest that this is solved :-)

On 2013-12-10 12:00 +0100, Joachim Hein wrote:> Nevertheless I'm not expected to downgrade cairo, I did a try and
> downgraded the libcairo package that was available for my linux
> distribution to version 1.12.8. and interestingly: This does not help
> either! What might be a useful information to the devs because this
> excludes a dependence from the cairo libraries (or library versions) in
> accordance with the observations that the behavior is not seen with
> rsvg-convert.

I don't fully agree with your conclusion ("this excludes a dependence from the cairo libraries"): your test narrows down which versions of cairo affect this problem (unless you want to invalidate all the tests I did earlier):

So far we know:
export ok: cairo <= 1.12.2
export not ok: cairo >= 1.12.8

You are completely right! I had in mind that 1.12.12 was tested working but reading again your comment #4 it was not.

Unfortunately, I have not found other cairo versions between 1.12.2 and 1.12.8 in repositories and for compiling it from source would take to much of my time. I'm sorry for that. So finally I installed 1.12.2 to be able to continue with my work I will be payed for. Actually there is not much I can contribute but I hope it was a little help reporting this issue. Thank you for your comments.

Upstream bug report:
73038 – recording surface with paint with alpha and clipping loses alpha
<https://bugs.freedesktop.org/show_bug.cgi?id=73038>

(confirmed still present with current cairo git master @ f88bd92 and Inkscape trunk r13113 on OS X 10.7.5)

Upstream proposed fix for cairo tested successfully on OS X 10.7.5 with
- cairo 1.14.2 + patch from
  https://bugs.freedesktop.org/show_bug.cgi?id=73038#c3
- Inkscape 0.91 r13725, 0.91+devel r14219
and the reduced test case from comment 6.

Confirmed fixed with upstream latest stable cairo release 1.14.4.

Hi there,

I have almost same problem with PDF. I have a SVG which I converted to PDF with Inkscape command line. After converting SVG to PDF transparent Clipart image disappears because of Clipping paths and Clip groups. Clipart is present in the file(can be seen in layers) but not visible. Attaching PDF layer screenshot and SVG file.

Below are the system and tool details.

System: Windows 7 64bit

Inkscape version: 0.92.2

Command: inkscape input.svg -A output.pdf

This happens with almost every SVG file which has a Transparent PNG file in it.

Please help me out.

PDF screenshot open in Illustrator