Upstream issue with rsvg

Thats not true, RSVG supports simple mask fully. Mask with gradients only partialy. For example https://commons.wikimedia.org/wiki/File:SVG_mask_gradient_bug.svg

kelvinsong10 wrote:

So, the same thing that can be achieved with Clipping paths. The whole point of masks is so you can apply opacity gradients/blurs!!! As it stands, the RSVG-supported masks are useless.

I removed the maskUnits="userSpaceOnUse" (in the mask tag) and the mask is working for this file!?

W3C cite: "If attribute ‘maskUnits’ is not specified, then the effect is as if a value of 'objectBoundingBox' were specified."

kelvinsong10 wrote:

Okay, I tried what you did, and it works!!! (The reason I reverted you at the file is because you didn't fix the mask—you flattened the masks and applied the opacity gradient directly to the pink rectangle). Sounds like an Inkscape bug then, as mask behavior doesn't seem to be seriously affected by removal of this property.

(In reply to comment #5)

Sounds like an Inkscape bug then

In that case, upstreaming it with a testcase would be welcome:
http://inkscape.org/report_bugs.php

Created attachment 13260
The original test case with default attributes filled in

In that case, upstreaming it with a testcase would be welcome:
http://inkscape.org/report_bugs.php

Re-opening. maskUnits is part of the spec, the fact its broken in rsvg is a bug in rsvg.

The fact that in this particular svg, the unit types in use don't make much of a difference doesn't mean this isn't a bug.

It appears rsvg does not have the correct defaults for the x, y, width and height attribute on <mask> when using userSpaceOnUse. According to the spec, I believe the correct defaults are -10%, -10%, 120%, 120% respectively. [1] (Assuming I interpreted spec correctly. I'm not really all that familiar with the details of the svg spec)

Attaching an svg with these defaults filled in, appears to make the file work fine for rsvg.

[1] http://www.w3.org/TR/SVG11/masking.html#MaskElementMaskUnitsAttribute

Attached:

Thanks for correcting.
So this should go upstream to https://bugzilla.gnome.org/buglist.cgi?query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;product=librsvg (though keeping bug 51555 in mind)?

(In reply to comment #7)

It appears rsvg does not have the correct defaults for the x, y, width and
height attribute on <mask> when using userSpaceOnUse. According to the spec,
I
believe the correct defaults are -10%, -10%, 120%, 120% respectively. [1]
(Assuming I interpreted spec correctly. I'm not really all that familiar with
the details of the svg spec)

I have a 4 line patch to rsvg that I think fixes the issue (Think being the operative word. I'm a c newb). I just spent 4 hours trying to make the thing compile at all, so I'm going to sleep on it, and then test it a bunch to make sure it actually works like I think it does. If so I'll file a bug/patch upstream and see what happens.

(In reply to comment #9)

I have a 4 line patch to rsvg that I think fixes the issue (Think being the
operative word. I'm a c newb). I just spent 4 hours trying to make the thing
compile at all, so I'm going to sleep on it, and then test it a bunch to make
sure it actually works like I think it does. If so I'll file a bug/patch
upstream and see what happens.

bawolff: Did you have time for that? Is there an upstream URL?

(In reply to comment #10)

(In reply to comment #9)

I have a 4 line patch to rsvg that I think fixes the issue (Think being the
operative word. I'm a c newb). I just spent 4 hours trying to make the thing
compile at all, so I'm going to sleep on it, and then test it a bunch to make
sure it actually works like I think it does. If so I'll file a bug/patch
upstream and see what happens.

bawolff: Did you have time for that? Is there an upstream URL?

Sorry not yet. Ill try to do that soon. My free time to do wiki stuff has somewhat evaporated.

bawolff: Understanding that you're busy, could you please share your untested four lines here so someone else would have the chance to test / improve a potential patch?

Created attachment 13897
patch to librsvg to change default mask size

(In reply to comment #12)

bawolff: Understanding that you're busy, could you please share your untested
four lines here so someone else would have the chance to test / improve a
potential patch?

Sorry, I meant to get back to this bug way before now, but I kind of forgot about this.

See the relavent section of the svg spec for where the numbers I chose came from.

Before submitting this upstream, I wanted to compile the patch on rsvg master (I was having trouble generating the build script, although I haven't put much effort into that. I did test on a modified version of the librsvg-2.39.0 tarball and it seemed to work well).

I also wanted to create a minimal test case for this before submitting upstream, which I haven't gotten around to yet.

Attached:

How does this relate to T8250?

I've created a category to make it easier to find examples where mask rendering fails.

https://commons.wikimedia.org/wiki/File:SVG_mask_gradient_bug.svg renders correctly on Commons SVG Checker only, which declares running under librsvg 2.40.2. (as @JoKalliauer mentioned on a testcase)

PS: But the leading example renders also not under CommonsSvgChecker.

Quoting Federico from https://gitlab.gnome.org/GNOME/librsvg/issues/105#note_83452 :

This is fixed in 2.42.3; possibly as low as 2.42.2.

Confirming fixed in 2.44.10

In T55899#1463965, @waldyrious wrote:

How does this relate to T8250?

I would close T8250 as a duplicate, also it is older because I find the description of this task better.