Since librsvg seems rather unmaintained and there seems to be no interest on side of the Wikimedia projects to consider using an alternative library on problematic SVGs I went on and fixed the underlying bug in librsvg myself.

See https://bugzilla.gnome.org/show_bug.cgi?id=605875#c9 for the patch. Sadly over at Gnome bugzilla nobody seems to be maintainig bug reports for librsvg or implementing patches given there. Therefore it's stuck right now.

If there are any Gnome developers around maybe you could have a look at it?

Sorry guys, but this bug hits nearly every image that uses the Gaussian blur filter effect. This is a serious limitation for SVG creation!

Can we please include the patch I posted upstream [1] in our local copy of rsvg until bug 51555 is solved in one way or another?

[1] https://bug605875.bugzilla-attachments.gnome.org/attachment.cgi?id=229516

• Bug 8566 has been marked as a duplicate of this bug. ***

This is finally fixed upstream!

librsvg 2.40.9 (just released) includes the fix. [1]

When / how can we get this for Wikimedia Wikis? Given the severity of this bug, it would be great to not have to wait until it's in the official Linux distro used on WMF servers...

http://apt.wikimedia.org/wikimedia/pool/main/libr/librsvg/

librsvg_2.40.2-1+wm1.debian.tar.gz 09-Jan-2015 09:46

https://packages.qa.debian.org/libr/librsvg.html

[2015-03-02] Accepted 2.40.8-1 in experimental (medium) (Iain Lane)

stable 2.36.1-2
testing 2.40.5-1
unstable 2.40.5-1
exp 2.40.8-1

upstream: http://ftp.gnome.org/pub/gnome/sources/librsvg/2.40/librsvg-2.40.9.tar.xz

adding _joe_ since he built librsvg (2.40.2-1+wm1) per debian/changelog

This is fixed upstream ??? Awesome, this really was one of the biggest problems with librsvg so far.
I'm sure the SVG users of the site will be super glad with this.

I think I made a mistake. Have been trying to deal with the ridiculous backlog on the Upstream workboard, because no one bothers to use it properly.

The upstream fix is in librsvg version 2.40.9 (which first needs to get packaged and shipped by the distribution running on WM servers).

@Krenair: Whoever created that board, "Patch merged" etc is so vague (in upstream? in WM downstream?) that I have no idea when to move cards anyway so I personally ignore it.

In T44090#1161511, @Aklapper wrote:

@Krenair: Whoever created that board, "Patch merged" etc is so vague (in upstream? in WM downstream?) that I have no idea when to move cards anyway so I personally ignore it.

I think it's probably supposed to be merged upstream. Would make sense. I didn't make it though. I think it should also include other upstream resolutions (e.g. Resolved, declined). Can we rename those columns?

I made it, and yes indeed Patch Merged was meant to indicate patch merged upstream. I figured we would add columns as we see need for them.

librsvg 2.40.9-2 is now in Debian testing. Is this enough to use it on Wikimedia servers?

@akosiaris please backport the package.

Another impressive example:

• https://cs.wikipedia.org/wiki/Wikipedista:Dvorapa/P%C3%ADskovi%C5%A1t%C4%9B/Broken_SVG_file

BTW not happy this issue is marked as a low priority :/

BTW not happy this issue is marked as a low priority :/

Don't get too excited. Priorities are meaningless

In T44090#1823750, @Bawolff wrote:

BTW not happy this issue is marked as a low priority :/

Don't get too excited. Priorities are meaningless

I don't know, e. g. in GitHub issues the priority is sometimes really important.

As noted above, this issue has been fixed in the rsvg library we use to convert SVG images to PNG. To resolve this issue on Commons, our copy of the library has to be updated, which is tracked as T112421: Update rsvg on the image scalers to 2.40.16 (to solve several SVG rendering issues). There's nothing else to do here other than wait for that to be done, and verify that it was fixed afterwards. That task actually has seen some movement recently, please watch it for updates :)

That bug is fixed on the new jessie image scaler using 2.4.16 (tested locally, it's not yet pooled into the set of active scalers in production). I have scaled https://cs.wikipedia.org/wiki/Wikipedista:Dvorapa/P%C3%ADskovi%C5%A1t%C4%9B/Broken_SVG_file#/media/File:Silverwiki_Hires.svg on the new and the present image scalers and put the results at https://people.wikimedia.org/~jmm/svg/ :

new-1.png / new-3.png are the results with approx. 100 and 300 pixels on the new scaler
old-1.png / old-3.png are the results with the existing scalers

(The pixel sizes differ slightly to prevent hitting the cached results in favour of a fresh scaler run)

@MoritzMuehlenhoff When could we await the fix to be in a release on Wikipedias (Czech)? In yesterday's MW release it wasn't (nothing changed). In the next one?

@Dvorapa This change is not a change in Mediawiki, but in the librsvg software component installed on the Wikimedia servers. As such, the change is already available on Wikimedia servers like Commons.

@MoritzMuehlenhoff I see, then it is only matter of time when it will arrive to other Wikis?

If any other Mediawiki installation wants to use the fixed version, it needs to install updated librsvg packages as well. For Debian jessie you can fetch the packages we use from https://people.wikimedia.org/~jmm/rsvg-backport-jessie/ and Ubuntu 16.04 provides recent enough packages as well. But maybe I'm misunderstanding you, are you referring to a specific file on Czech Wikipedia?

@MoritzMuehlenhoff I just want to fix this on Czech Wikipedia. The file is uploaded on Commons, but on the Czech Wikipedia the preview is still broken. This is the reason why we can't remake all our barnstars and badges on the Czech Wikipedia from PNG to SVG (it looks broken even if perfectly valid SVG 1.1 file)

@Dvorapa I see the files ok, please check your browser cache.

@jcrespo I see, thank you, it must be from today, because yesterday purging server and browser cache didn't help

@Dvorapa The confusion we are seeing here is probably a bit logical. The issues is fixed, BUT any image that is affected will have to be manually purged. You can easily do this, by going to the file description page on commons and added "?action=purge" at the end of the URL.

@TheDJ I see, thank you