Preview not matching the export with clipped group

[OriginalEXE]

Description/Steps to reproduce

Hello, I am using your library and it has been serving me great so far, thanks!

I believe I ran into another interesting bug. On some shapes (not all of them) it looks like the clipping group is "leaking" its contents. The interesting thing is that when I export the SVG, it looks great, so this issue only affects the canvas.

NOTE: When you are testing the export of an SVG, make sure to open the clipPath inside the defs and remove the group that wraps one of the paths, that's a bug from my other issue.

Link to reproduction test-case

Sketch

Expected result

The canvas clipped group should not "leak" its contents and should match the exported SVG appearance

[sasensi]

Hi, thanks for the report, just to clarify the bug:

• expected:
• actual:

[OriginalEXE]

Correct. It only happens with some butterfly shapes, for others it works as expected. Very weird.

[sasensi]

The reason behind this bug is that you are clipping with a group which is itself clipped. If you look closer at what is imported in your svgClipItem variable, you'll see that what is imported is a group containing the butterfly path which is clipped by a rectangle shape. This is due to the presence of a viewBox attribute on your <svg> tag. Here is the code that makes the group clipped in this case: https://github.com/paperjs/paper.js/blob/b1705f628b829fe296d8191adbb8016fea09dc49/src/svg/SvgImport.js#L483-L488 So you can easily workaround this issue:

• by removing viewBox attribute in you <svg>: see this sketch.
• by manually removing this unneeded rectangular clip mask after importing. Here is a sketch demonstrating the workaround. The core part is:

  // Import svg as a clipped group.
  var svgClipItem = paper.project.importSVG(svgClip);
  // Extract the path we are interested in.
  var realClipPath = svgClipItem.lastChild.clone();
  // Remove the rest.
  svgClipItem.remove();
  // Set the extracted path as variable value.
  svgClipItem = realClipPath;

Here is a sketch reducing the bug to a simple case.

• Expected:
• Actual:

[OriginalEXE]

Oh wow, thank you for a detailed explanation, it makes sense! I will try it in a few hours and will report back, but I expect that that's it, thank you very much for your continued support, very appreciated!

[sasensi]

This seems more generally related to the fact that we only support path as clip item and should be solved by something like #59.

[OriginalEXE]

I used the lastChild cloning method, and it works flawlessly, thanks again, Samuel!