@AntiCompositeNumber : Thanks for your answer, I think I was wrong.

Thanks for fixing! :-D The bug-request seems to be solve

@Aklapper I'm not shure if the file is invalid, if I insert the source-code in https://validator.w3.org/#validate_by_input there are only warnings, but no error. (i.e. valid)

@Samwilson I like this solution. (Maybe a bit different wording, as @Glrx explained.)

In T250607#6089656, @aezell wrote:

Potentially, we could skip the nested TSPANs and still allow users to translate the unnested ones. In that sense, this could be considered broken behavior since it completely fails now.

My guess is that the tool gives up on an entire file when it runs into a pattern that it cannot process.

@Glrx Thanks! The tool is better than I thought. :-D

@Glrx Your descrition does imho not relate to his bug.

In T193352#6003571, @Esanders wrote:

That is a common SVGO problem

Is SVGO actually violating the spec, or is this just a bug in librsvg?

I think this issue is caused by T36947

I think this issue is related to T36947

@Esanders : Your bug is imho T217990 and can be fixed using https://tools.wmflabs.org/svgworkaroundbot/ (activate "run svgcleaner"). It is related to missing spaces between arc-to-flags. That is a common SVGO problem, you should try https://github.com/scour-project/scour and https://github.com/RazrFalcon/svgcleaner instead, which are imho less buggy and sometimes even offer woraounds for librsvg-bugs. (so they often repair svgs; and hardly break them)

How can I close/mark it as duplicate of T208620 ?

@Aklapper : According to your comment T193300#4166078, I have to correct myself (T193300#4444133) inkscape uses cairo-backend (also librsvg uses cairo-backend REF ), see https://gitlab.com/inkscape/inkscape/issues/1063#note_297298220 (ping to @RazrFalcon )

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 (and also Browsers normally render according to the standard)? 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