@hnowlan : Do I understand you correctly that all svgs on Wikimedia-Commons are currently rendered by librsvg-2.54.7 ? So this task can be closed as completed (Status: Resolved)?

The problem also occurs locally with librsvg 2.52.3, but does not occur with 2.40.21 on https://svgcheck.toolforge.org/index.php. I assume a regression in librsvg.

@Aklapper : I undo your lowering of the priority in 2015, since according to https://www.mediawiki.org/wiki/User:JoKalliauer/phab/wikimedia-svg-rendering#table (updated till ~2023) it is the 8th most important (out of 94 bugs) in the category Wikimedia-SVG-rendering . To be more objective, it is afaik according to subscribers the 1st place of bugs in Wikimedia-SVG-rendering (afaik 4th place of all open tasks), which is approximately the border between "low" and "medium" important bugs. Even though it is easy fixable bug (e.g. automatic by User:SVGWorkaroundBot or on toolforge ), I would rather consider it as a medium bug, since it is a common bug.

I think we should fix all files, by making any edit (e.g. adding ´<?xml version="1.0" encoding="UTF-8"?>´), as I did on the last mentioned file.
Since it does not affect newly uploaded files we might consider closing it.
It only affects files from ~March 2016? (e.g. 7.March 2016 to 27.March 2016)

In T370044#10033078, @Glrx wrote:

Could someone please check if this problem persists in more recent librsvg versions? Thanks.

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