Only the first child of a mask is considered by Inkscape

[henrypijames]

Inkscape version: 0.48.1 r9760 on Windows XP x86

Sample SVG producing the bug see attachment or:

http://paste2.org/p/1458206

Not only does it misrender on screen, export to EMF is even worse (try save as EMF and then load the EMF back).

File renders correctly in Firefox 4, Safari 5 and Opera 11; Chrome 11 has a different problem with it (regarding mask + transform, apparently).

[su_v (suv-lp)]

Reproduced with Inkscape 0.48.1 and Inkscape 0.48+devel r10262 on Mac OS X 10.5.8 (i386)
Compared to Firefox 3.6, Safari 5.0.4 , Opera 11.11, Chromium 14.0.786.0 and Squiggle (Batik 18pre)
rsvg-view (librsvg 2.34.0) completely fails to render the masks.

Works if the two masking objects are inside a group (i.e. masked with a group).
Using classes or a 'style' attribute doesn't make a difference.

[su_v (suv-lp)]

Forgot to add: all mentioned browsers render the SVG file identically, the only renderer that completely failed was rsvg. Inkscape "omits" the dot in the mask of the upper object.

EMF export not tested (only available on Windows).

[su_v (suv-lp)]

> export to EMF is even worse

Please file a separate report about EMF export, possibly with a screenshot illustrating the errors in the EMF file.
If the issue with EMF export is not limited to this particular file but masking in general, it could be related to Bug #649744 “emf wmf export clipping path issue” (export to EMF completely ignores the clipping path).

[Alvin Penner (apenner)]

attached is the emf file obtained with dev build 10255, on Windows XP.
this does not recognize the clipping paths, similar to Bug 649744

[su_v (suv-lp)]

Also reported and discussed in bug #901198.

Setting bug importance to 'Medium' (compliance to the SVG specification is a major goal on the roadmap): even though Inkscape itself does not create such masks (it only uses the top-most (or bottom-most) object of a selection as mask), it should properly render externally created valid SVG files with masks like in the reported case(s).

[kaspar (kaspar-emanuel)]

I believe our renders not showing up in Inkscape is related to this, though I can't even work around it by grouping elements within mask. Any insights as to why even the grouped version doesn't show up in Inkscape?

from https://github.com/tracespace/pcb-stackup

[kaspar (kaspar-emanuel)]

Meant to link: https://github.com/tracespace/pcb-stackup/issues/29

[Hachmann (marenhachmann)]

The bug description doesn't entirely fit my testing:

- in the areas where the mask objects do not intersect, they both work as expected
- the order of the mask objects does not appear to make a difference (0.92.3), I've reordered them and always got the same result (unless it's not being updated)

See also:
http://www.inkscapeforum.com/viewtopic.php?f=29&t=33561

[Nathan Lee (nathan.lee)]

1.0 appimage, and Inkscape 1.0.2 (f38d80df83, 2021-05-16), Inkscape 1.2-dev (c903a5148f, 2022-01-31) no longer experience the issue with dice.svg.

0.92.x still experiences it, so I would say fixed (and I didn't misread the issue). Doing a bisection fixed by 298c79f467515176f2eab71678971d8a18ace6a5 Thomas Holder fix https://gitlab.com/inkscape/inkscape/-/issues/810 Mask child order

EMF issue still exists, using Libreoffice drawing to view export. Looks like opacity is just ignored, see https://gitlab.com/inkscape/inkscape/-/issues/997

The 8bit*.svg files still don't work, though we also run into issues with currentColor (I don't think we support that for paths) and CSS styling. I notice one path in the mask has fill="none", which I assume is meant to be overridden by `#Hyn47AQ__top_out path {fill: #fff; stroke-width: 0;}` , however I think fill="none" should take precedence?

Anyhow, replacing currentColor with the CSS defined colors, and fill="none" with fill="#fff" is enough to make the renderings match firefox (at least at a glance) in Inkscape 1.2-dev.

Re: Maren's testing:
- Not sure about the area (since one is white, if it's not intersecting, it'll have the same behavior as doing nothing?) I do see something odd, but it's gone in 1.0, so no point clarifying.
- Replicate moving ordering not changing result. Yes, bug. Save and restart changes rendering (also you'd expect it to). Reported at https://gitlab.com/inkscape/inbox/-/issues/6295

-------------

Note: we've moved to Gitlab as our bug tracker, the still existing issues (with the 8bit*.svg files) should be migrated there, but I've just left a comment here to avoid retesting.

New issues can be reported to inkscape.org/report (which should redirect to our current bugtracker). Thanks for the report!

[Nathan Lee (nathan.lee)]

Trying to produce a minimal case for the 8bit*.svg, every assumption I made was wrong.

Okay Inkscape does handle currentColor in objects just fine.

The problem is that

1. stylesheet was broken by `/* <![CDATA[ */.` If I add a whitespace after the end of the comment (and before the other comment), it seems to work. https://gitlab.com/inkscape/inbox/-/issues/6297
2. Inkscape doesn't support color rgba. I'd have to check if it meets the svg specs, probably I guess. Changing it to `color: rgb(00, 66, 00); opacity: 0.75;` works. Reported in https://gitlab.com/inkscape/inbox/-/issues/1195

And so all the above issues should be reported on GitLab now, or fixed in 1.2-dev or earlier.

Thanks again for reporting, and please open a report at inkscape.org/report if I missed anything.