Inkscape

SVG clip-path on <clipPath> not respected

Bug #567014 reported by Mo DeJong
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Inkscape
Confirmed
Low
Unassigned

Bug Description

Hello

In 14.3.5 of the SVG spec:

If a valid 'clip-path' reference is placed on a 'clipPath' element, the resulting clipping path is the intersection of the contents of the 'clipPath' element with the referenced clipping path.

Inkscape and the current firefox both fail to render the attached small example correctly. I have included a PNG example of what the output should look like. When processing a <clipPath>, if it has a clip-path="url(#clip)" attribute, then the referenced clip path should be intersected with the current clip path before processing the elements inside the <clipPath> and doing the second clip path intersection.

Tags: clipping svg
Revision history for this message
Mo DeJong (mosesdejong) wrote :
su_v (suv-lp)
tags: added: clipping
jazzynico (jazzynico)
tags: added: svg
Revision history for this message
jazzynico (jazzynico) wrote :

Confirmed on Vista, Inkscape trunk revision 9983.
Also fails with Firefox 3.6, but works with Opera 11.

Changed in inkscape:
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
Mikhail Ryazanov (michael-ryazanov) wrote :

Still not fixed...
It is even more interesting that the specification read further: "If a valid ‘clip-path’ reference is placed on one of the children of a ‘clipPath’ element, then the given child element is clipped by the referenced clipping path before OR'ing the silhouette of the child element with the silhouettes of the other child elements.", and that situation works differently in Inkscape (0.48.2 r9819). Namely, clip-path attribute of <clipPath> is ignored completely, but clip-path attribute of a child adds clipping to the bounding box instead of the actual path.
See the attached file (based on http://apike.ca/prog_svg_clip.html):
"Intersection" was made by nesting clip paths (one for <g>, another for <rect>) — it looks correct.
"Intersection1" uses clip-path attribute of <clipPath> — no effect in Inkscape.
"Intersection2" uses clip-path attribute of a child path — Inkscape clips to the clip-path's bounding box (warning: would produce a correctly looking result for unrotated rectangles).

P.S. Is there any standard-compliant tool to convert SVG to EPS/PDF?

Revision history for this message
Matěj Cepl (mcepl) wrote :

Just to note that Firefox 23 now renders the SVG correctly. Not that it would have that much relevance for this bug.

Revision history for this message
Beluga (buovjaga) wrote :

Still confirmed with ClipPathInt1.svg

Arch Linux 64-bit, KDE Plasma 5
Inkscape 0.92+devel 15099 (GTK3)

Revision history for this message
maxbellec (maxbellec2) wrote :

Still confirmed (OS X, Inkscape 0.91). This is a very annoying bug for me.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.