librsvg (alternatively "RSVG") is the rendering library of GNOME used by MediaWiki for rasterizing SVG image into PNG format. It was chosen for its efficiency over accuracy. Rendering SVG in real-time by modern browser can be challenging for older computers, a raster image (within reasonable size) can alleviate that burden for our readers in limited circumstances, at the primary cost of SVG interaction. However, maintenance of librsvg is nearly dormant. Since 2014, many major bugs which have been reported for years are not fixed or reviewed for application, its sole maintainer wrote in a private email stating that "librsvg is in deep-freeze maintenance mode, and I've been mainly doing minor bug-fix releases."[1]
The bad influences by the lack of proper updates of the library include:
Vector artists use workaround which sacrifices text in its raw form for neat rasterized result, resulting more difficult localization for other contributors, because they will have to re-position all text labels by themselves instead of only modifying the existing text.
Vector artists just avoid SVG format altogether and instead contribute image in other less modifiable formats such as PDF or any raster format instead, because the bugs of librsvg are prohibitive for them to achieve the desirable graphic effect.
While still at the planned stage, SVG 2.0 is unlikely to be implemented into librsvg because this upgrade from the current version 1.1 is huge. Once most major browsers begin support of SVG 2.0 specification, Wikimedia will be labeled as a ground of outdated technology and further discourage artist to contribute valuable SVG images.
Contents in the style element is ignored if its "type" property is not given the "text/css" value which should be the default value specified by W3.[2]
When a path using middle marker and its path data containing cubic Bézier curve command (either complete or shorthand) whose second control point's location is the same as the destination (e.g. C 3,6 20,20 20,20), the middle marker and all subsequent elements are not rendered. (Commons discussion)
Does not support space for separating between stroke-dasharray values (e.g. stroke-dasharray="1 2 3" compared to stroke-dasharray="1,2,3". [4]
Font kerning appears misinterpreted when text is scaled. It does not matter if the given scaling value is 0.5 or power of 2. This happens anyway whether only individual text or the whole image is scaled.
textPath not supported, worse text with textPath applied will disappear or displaced. Patch not reviewed or implemented. [5]
If the filter effect (e.g. gaussian blur) exceeds the edge of the image canvas, it will look like a clipPath of the same size as the canvas being applied before the application of the filter effect. (Example, compare between on-site render and browser native render.) This could be an intended design for the sake of rendering speed but is annoying to artists anyway.
