Comparison with other renderings: It seems to be a general problem

• resvg: https://github.com/RazrFalcon/resvg/issues/234
• inkscape: https://gitlab.com/inkscape/inkscape/-/issues/928

The issue still exist in librsvg 2.51.1

Rendering of librsvg 2.51.1 compared to resvg, chrome, batik and Inkscape and others.

@4nn1l2 :
FreeMono fallback to DejaVu Sans Mono
FreeSerif falback to DejaVu Serif
see https://upload.wikimedia.org/wikipedia/commons/thumb/archive/b/bd/20210505084110%21Test.svg/1200px-Test.svg.png (The red DejaVu is imho identical to the green FreeMono/FreeSerif)

I do not care (that much) if we change to resvg or inkscape (or similar), however to stick to librsvg (even the current version is too buggy) just because we do not know how to decide is imho the wrong way to go.

From the Discussion on Inkscape about getting the Wikipedia-renderer

If we mean that a minimized SVG-version of the uploaded SVG should be saved: I would say a clear no. (If we talk about client-side-rendering that might be different.)

In T139168#2422485, @Bawolff wrote:

Unlike PDFs, we do try to detect malicious files (albeit, not perfectly), and the type of exploits that malicious pdfs have done are quite a bit worse then what someone can do with a malicious svg in a browser. (barring browser bugs)

@AntiCompositeNumber : Fixed in librsvg 2.52, see https://gitlab.gnome.org/GNOME/librsvg/-/issues/646

I reported it upstream: https://gitlab.gnome.org/GNOME/librsvg/-/issues/720 (with rsvg-convert version 2.48.9)

@Glrx: Is there a definition in the W3C-Standard that Quotes are allowed?

@Aklapper : I would remove Wikimedia-SVG-rendering. https://phabricator.wikimedia.org/tag/wikimedia-svg-rendering/ it is imho not about server-side-rendering of svgs .

Yes this character seems to be a font-issue. However it is strange, why now resvg does not render any characters any more on the same computer (I run in the meantime sudo dnf install google-noto-\*)

@Glrx:
client side rendering; animated SVGs
I agree on that whitelisted SVG should be rendered on client side ( T5593 ), with opt-out or opt-in in the preferences.
Animated Gifs and Videos (e.g. webm) are imho still the golden html-standard. I hardly see animated svgs on the web, however I think thats also an advantage of client-side-rendering, since animated svg-converter are hardly known (imho e.g GPAC, and animated SVGs, animated GIFs and movies have a imho different scope.

Is there a rough guess for the time-limit? @Ponor and I get completely different times for a svg-benchmark T40010#7031600 , there are several reasons for that see User_talk:Ponor. The most imporant difference might be e.g. segmentation fault after 7minutes of rendering-time (on a single CPU).

I'm making a svg benchmark, containing of three test suites

• https://www.w3.org/Graphics/SVG/Test/20110816/
• https://github.com/RazrFalcon/resvg/tree/master/tests/svg
• https://commons.wikimedia.org/wiki/Category:Featured_pictures_on_Wikimedia_Commons_-_vector

and the four render

• librsvg
• resvg
• Inkscape
• batik

In T280718#7023966, @akosiaris wrote:

[...] I propose we remove that file from mediawik-config repo altogether. It's already 3.5 years out of date, if anything relies on it, it's relying on very old data.

Actually the file is from a SVG-test, decalring that
*chrome/firefox/librsvg 2.51 renders it correct
*resvg/inkscape/batik and others render it wrong

There is a tool on toolforge: https://svgworkaroundbot.toolforge.org/

@akosiaris
I think it is important to define "safe fonts" that are available to librsvg for commons (and also for SVGChecker see T280722), how it is done might not be so important (at least for me).

Yes a typo

In T280721#7022037, @Dzahn wrote:

There is no difference between different servers that could explain different rendering results, if those files were rendered at the same time.

@Dzahn : I noticed some encoding-Problems:

• 575: Ani,অনি Dvf should be Ani,অনি Dvf
• 148: Mitra Mono,\\u09ae\\u09bf\\u09a4\\u09cd\\u09b0 should be Mitra Mono,মিত্র
• 294: Mukti Narrow,মুক্তি should be Mukti Narrow, মুক্তি পাতনা

In T246014#6543544, @AntiCompositeNumber wrote:

• MediaWiki also calculates the size of SVG files. Our default DPI should match whatever MediaWiki does.
• How would this affect the visual output, considering that most images are displayed with a fixed width in pixels?

(1) the dpi is relevant if a file has (a) no viewBox and (b) height/width that are not in px
(2) the dpi of MediaWiki change the peviewsize if a file has (a) a viewBox and (b) height/width not in px

The files of the test-suite are already uploaded for the SVG_test_suites . Since the namespace does not change rendering, this is not such a big issue, to replace it, even all W3C-files had to get changed. Some other IllegalPatterns which effect rendering are more relevant, some of them are blocked purposely, others like T279239 T279240 are imho blocked by error. => So editing the test-suite is anyhow necessary (at least for some files), which reduces the priority of this task.

Such SVG can be "repaired" (lossless workaround) using https://svgworkaroundbot.toolforge.org/ (enable "run svgcleaner").

@Aklapper I do not know which SVGs get's blocked and which are allowed. I uploaded W3C_SVG_1.1_test_suite and found several patterns unintentionally , and documented them yesterday on Help:SVG and added a option to santizice SVGs on https://svgworkaroundbot.toolforge.org/ . Even I edited SVGs by source-code, I had problems in understanding some error-messages, and what's the problem. Newbies often do not know the difference between jpg, svgz, pdf, for them it is imho impossible to understand the message, even if they know that svg have a soucre-code, that might be edited by text-editor. I would like to know what's blocked, and to be able to refer to it.

@Glrx I agree in general it would be poor method to not define dimensions, however it is valid example from the W3C-Test-suite, therefore MediaWiki should take the dimensions of librsvg. And it is imho not the creators fault, that is done on purpose in the official test-suite. If it is not supported it is a bug!
I know it is a hardly supported feature, however it is more a general problem.
For example if librsvg renders an image in 512x383, but due to rounding-errors MediaWiki assumes 512x384, it should not get distorted, it will make the image blurry.
The image should imho be embedded without height="..." or with object-fit="none", or anything else that does not change the aspect ratio,

I made a commit https://gerrit.wikimedia.org/r/c/mediawiki/core/+/676146/1/includes/upload/UploadBase.php

Generally I would just remove the description, however it is a testsuite and should be kept unmodified, for more infos check: https://commons.wikimedia.org/wiki/User:JoKalliauer/SVG_test_suites#W3C_SVG_1.1_test_suite

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