The last 3 version of https://commons.wikimedia.org/wiki/File:Oxygen480-mimetypes-image-vnd.dwg.svg already contains a workaround so that the last version renders at the preview-size of 120px.

mix-blend-mode is not part of the current SVG 1.1-Secifications, therefore ignoring is imho technically correct, see also https://github.com/RazrFalcon/resvg/issues/240#issuecomment-592200025 or https://github.com/RazrFalcon/resvg/issues/243#issuecomment-592811200

I assume that is because the cache is not purged

@Glrx: According to T65236#8458679 the SVG-file has been fixed, could you provide an image that currently provides this issue and edit the task-description. (Otherwise I find it unclear&confusing.)

I'm not shure if it helps if I provide simple SVG-examples with systemLanguage=

Could someone update https://noc.wikimedia.org/conf/fc-list

If I compare Chrome113 and Firefox113 the svg looks very different: (on Fedora38)

@TheDJ The reported image is still not rendered correctly (middle bottom has a imprecise gradient), however the reported issue of @Glrx is resolved/fixed.

again confirming fix

now the file is rendered according to SVG2.0 (resolved)

1. unclear description

As per previous comments by Glrx and Aklapper, this bug-report is (now) unclear to me.
If the problem persists please provide a minimal (not) working example, showing the specific problem.

librsvg2.52 will set the default to 96dpi see https://gitlab.gnome.org/GNOME/librsvg/-/issues/646, maybe we should set 96dpi.

it seems to be fixed

it seems to be fixed

both not correct

confirm fix

confirm fix

The spacing in https://commons.wikimedia.org/wiki/File:Types_of_Sentences-pa.svg is still not perfect.

There might still be kerning issues, however I consider this issue as resolved.

This update might trigged a difference in rendering between SVG-check vs Commons-Rendering, see T335415 (not only the font is different also the alignment is different on small thumbnails)

I think it is diffciult to reproduce it now, and this image is related to other rendering-bugs, therefore based on the comment by @Umherirrender in T228433#8794434 I close it as Resolved.

@Umherirrender ; You have to compare the PNG not the SVG, because the rendering has several rendering librsvg-bugs

In T282864#8544224, @taavi wrote:

apt-browser displays which packages are available with a given component, and that's working correctly. It does *not* display which packages have been installed on a specific host.

librsvg which runs on Thumbor is still on strech

Please check https://packages.debian.org/search?searchon=sourcenames&keywords=librsvg

@Jdforrester-WMF : Please update the description at T216815 which currently states:

Upgade Thumbor from Debian stretch to Debian bullseye

I can reproduce this on Android 11.

@Dzahn: Thanks and packing resvg from https://github.com/RazrFalcon/resvg/ might be out of scope?

@Ahecht: If supporting the latest version of librsvg is difficult, some Users prefer (i) resvg (faster and less regressions than updating librsvg) or (ii) Inkscape (slower but better know by the community), as documented at T40010.

Maybe it is not buggy for the developers since I know only few cases wher SVGo couln't create an "optimized" SVG from a Commons-SVG, however those so called "optimized" SVGs are often broken (=don't render as intended). SVGo already broke too many SVG-files on commons, that's why (SVGo-)Users reuploading "optimized" SVG-files get reproved on commons, see Commons:SVG guideline for details. The damage-rate of any optimizer is way too high, expecially of the default settings of SVGo. Maybe you deactivated the most problematic ones. I just pointed out 6 common SVGo-Bugs for SVG-files on Commons on your talkpage. Can you tell me your settings and I can tell you the relevant bugs relating to those settings (even if you deacitate everything, svgo still breaks files).