Dear Commons community, the WMF Technical Committee (link) is currently weighing an RFC (link to this one) which is basically about changing the SVG renderer. What this means is that some SVG that currently renders correctly will no longer render correctly. But that many of the current rendering issues could be solved. We think this could be a good idea, but would prefer if someone could organize what happens if/when images break. Without someone performing that product manager role, we think this switch would not be very successful. Does someone here want to take on that kind of work? Broken renderings must be identified, and if the renderer is at fault bug reports filed. If the file was at fault, the file must be fixed -- or at least organized into a list that the community can work from. We could provide a tool for testing individual images, but need people to run through them identifying what's actually wrong (if anything) when a file renders differently.

Due to performance reasons it might be the expected result to not check large SVGs till the end for <switch-tags.

In T243893#5874557, @Krinkle wrote:

Note that if we're mainly interested in comparing SVG renderings, it might be easier to do that offline rather than already doing all the pre-production prep work for Beta Cluster. That way it only has to be installed for you locally and not in Beta Cluster. Any comparisons we want to do (e.g. pick 1000 most used or random SVGs from Commons, render side-by-side and generate SSIM scores perhaps?) can just as well be done locally, I think?

In T40010#6635673, @Ponor wrote:

For, you see, Inkscape will always be the best converter for whatever Inkscape can produce. I hope we can agree on that.

In T40010#6634341, @Aklapper wrote:

cf. T19012: Attach source files (in their original file format) to uploaded images

1)For LaTeX there is no need to need to upload a LaTeX-file just put it the source-code into the description.
Gnuplot-Example: https://commons.wikimedia.org/wiki/File:Drini_nonuniformconvergence_SVG.svg#filedesc
LaTeX-Example: https://commons.wikimedia.org/wiki/File:LaTeX_logo.svg#filedesc

@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?