In T40010#5921789, @Milimetric wrote:

Clarifying question. If I could run all our SVGs through a checker using resvg to find out what bugs they suffer from, is it possible to write such a checker?

Common librsvg-bugs are known and some of them can be checked by Commons:Commons SVG Checker which are listed here: https://commons.wikimedia.org/wiki/Commons:Commons_SVG_Checker/KnownBugs
But writing a bug-checker for malformed files for librsvg-bugs (I did not know such files exist) is maybe even more difficult than render the file correclty. (So ~impossible) (For some few it is maybe possible, but there exist imho not a common one.)

Re-evaluate librsvg

• with non-Commons-files is like comparing apples with oranges (Quting from https://github.com/RazrFalcon/resvg#performance )
• with Commons-files is very tricky, how do you handle malformed files optimized for librsvgbugs, which should render differently according to the SVG1.1-W3C-DTD? Such as rsvg-Bug565, rsvg-Bug566, rsvg-Bug567 (T246003 T246001 T245864 T246014, but on GNOME you can see it better)

reported in https://gitlab.gnome.org/GNOME/librsvg/issues/567

In T246001#5912318, @Aklapper wrote:

As this seems to be a librsvg issue, might be worth to report to upstream at https://gitlab.gnome.org/GNOME/librsvg/issues/ ?

In T246003#5912850, @Aklapper wrote:

Feel free to upstream at https://gitlab.gnome.org/GNOME/librsvg/issues/ , I'd say. Can still reproduce with librsvg 2.46.4

@Aklapper Yes it is about wrong PNG-rendering.

@Aklapper here the data from https://github.com/RazrFalcon/resvg#svg-support

In T5537#5794910, @Bawolff wrote:

That sounds like its working as it should (?)

@jijiki : The Problem is not persisting for uploaded files(after ?action=purge, since I guess ~2012), but new files can't be uploaded any more, see first Bug in https://commons.wikimedia.org/wiki/Commons:Commons_SVG_Checker/KnownBugs .

Please note "This diagram was created with Inkscape, and then manually edited." under Summary in https://commons.wikimedia.org/wiki/File:Double-slit.svg so this case is not very common. We can take another look if this becomes a bigger problem.

In T230357#5787399, @HMonroy wrote:

This file contains a non-standard SVG format that it is not currently supported .

@Aklapper : https://gitlab.gnome.org/GNOME/librsvg/issues/17 should in my opinion be resolved because text-decoration="underline" works but overline doesn't, see https://commons.wikimedia.org/wiki/File:T15495_(resolved).svg , see also https://bugzilla.gnome.org/show_bug.cgi?id=524433 and https://phabricator.wikimedia.org/T15495

Sorry for not answering. I didn't have access to a PC (holyday and repair of my private one) and I am no longer able to reproduce this bug.

https://commons.wikimedia.org/wiki/File:T20936_Hairline_cracks.svg
has hairline-cracks all over (from an actual image: File:Two_way_complex_manifold.svg)
you can't even recognise the image any more. (Firefox has the same bug, but chrome not)

@OSeveno : Change the proposal as you like

I tried it with Chromium 74 on Ubuntu 18.04, with the same result, so it seems to be independend on the browser and OS, so I think it is user-related.

@AfroThundr3007730 : According to https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Archive/Option_to_embed_SVGs_as_SVGs supporting native client-side SVG rendering seems to be impossible/stalled within the next years, not even for specific SVGs T208578 .
Anyway if someone whats to render it on client-side (f.e. animated SVGs) it is possible T5593#5234639 .

@AfroThundr3007730 : The description is "Please add an option to allow client side SVG rendering.", therfore in my opinion this request/task is resolved, but I would agree there should be another new phabricator-Task about "Native client-side SVG rendering, without relying on third-party scripts".

In T5593#5234639, @Habitator_terrae wrote:

If you're intersted in see SVGs here is a script for you.

@Aklapper
I assume it is a bug related to me (my computer/my browers/my extensions/my preferences/my username/my whatsoever)

@Niharika : No it still does not work

@Incnis_Mrsi :
Please check the differences in Rendering between

SVG 1.2	SVG 1.1

Thanks for your opinion. You are very exprienced in fonts (attributes,W3C,systemLanguage,...) and I really value your opinion.

@Jarry1250 : Actually since last week librsvg 2.40.20 is installed on servers, therfore we might should change the title. (Update librsvg to 2.40.20 on toolforge)

In T68672#5110845, @jijiki wrote:

Since last week all servers are using librsvg 2.40.20-3 which fixes some svg rendering issues (and possibly introduces others).

@Aklapper Was there an recent (this week) update or something?

@Aklapper Was there an recent (this week) update or something?

@Aklapper Thanks! I reported this issue at https://github.com/danmichaelo/croptool/issues/133

Can we use https://tools.wmflabs.org/svgcheck/index.php instead? It seems to work.

@jijiki Sorry, but this is a duplicate of T36947

@Great_Brightstar :
I used the current (02:11, 21. Mär. 2014 idenical to first) svg:
https://upload.wikimedia.org/wikipedia/commons/archive/5/5a/20140321020128%212014%E5%A4%A7%E8%BF%9E%E7%BB%B4%E5%9F%BA%E4%BA%BA%E6%98%A5%E5%AD%A3%E8%80%83%E5%AF%9F%E5%9B%A2%E6%B5%B7%E6%8A%A5%E7%AB%96%E7%89%88.svg

In T65236#4800144, @Aklapper wrote:

Ah, thanks! I did not compare well, because this is how it looks when I open that image in inkscape-0.92.3-5 using librsvg2-2.44.8-1:

In T193352#4704483, @Aklapper wrote:

@JoKalliauer: I'm not a fan of generic "Update X" tasks without any goal or target, as they easily become neverending catch-all tasks. Which specific version/branch is wanted in this task? 2.42/2.44? Something else?