Clipping renders object invisible in browsers

Attaching reduced test case: possible trigger seems to be a disagreement about the clip-path itself (a group of 4 paths).

Reproduced with Firefox 12.0 Safari 5.1.4, Opera 12 and Chromium 22.0.1189.0 on OS X 10.7.4
Only Squiggle (Batik 1.7) agrees with Inkscape (0.48.x, current trunk).

> (…) a disagreement about the clip-path itself (a group of 4 paths).

Setting bug status to "Confirmed" for now -> needs further investigation (which renderers are correctly interpreting the current SVG specification).

Another variation of the reduced test case: Clipping also works in browsers if the four paths describing the clip-path are not nested inside a group inside the <clipPath> definition (they don't have to be unioned into a single path).

See also:
* Bug #1441152 “Create Clip Group generates invalid SVG”
  https://bugs.launchpad.net/inkscape/+bug/1441152

As discussed on irc in the context of bug #1441152, the SVG specification does not allow <g> as child element(s) of a <clipPath> element:
«A ‘clipPath’ element can contain ‘path’ elements, ‘text’ elements, basic shapes (such as ‘circle’) or a ‘use’ element. If a ‘use’ element is a child of a ‘clipPath’ element, it must directly reference ‘path’, ‘text’ or basic shape elements. Indirect references are an error (see Error processing).»

Inkscape OTOH does create <clipPath> elements which may contain groups (<g>) - such clippings do not conform to the SVG specification and AFAIU other SVG renderer seem correct in not rendering the clipped elements at all.

Changing Importance to 'High' (inkscape creates non-conforming SVG when clipping with a group of paths).

Should be noted viewing through IE now renders the original SVG properly.

The file hosters have expired, and the sample files are not available.
Please re-open a report on https://gitlab.com/inkscape/inbox/issues if this still appears.
Closing because this can't be reproduced without sample files.

Closed by: https://gitlab.com/mray