RFC Wikimedia re-evaluates svg-renderer
Librsvg 2.50 (differently to resvg/inkscape)
- does not support textPath at all, see textPath-examples
- has unacceptable kering-errors (T36947#7062325 , T205776#7072788, T142908#7072828 )
- does not support lists of x-coordinates T35245
- does not render patterns on small scales T20463#5013832
so this and other issues raise the question if Wikimedia should stick with librsvg.
rendersvg is widely unknown, but it is way faster and imho has a much better SVG1.1-Support. Inkscape on the other hand is much slower but has a very good SVG2.0-support (SVG2.0 is imho currently not very important on commons). If you check the benchmark at https://commons.wikimedia.org/wiki/User:JoKalliauer/SVG_test_suites#summary you will see that resvg wins 7 out of 7 tests(4times speed 3times correctness), between librsvg/resvg/Inkscape/batik. Headless browsers might also be a valid option, which are not included in the benchmark, which would have the advantage of similar rending as client-side-browser-rendering.
On phabricator there is slow progressing request of re-evaluationg renderer. rsvg and inkscape, as the imho two most promising candidates, joined the discussion on phabricator. So it would be nice if you could also add your opinion about changing renderer.
WMF-developers are imho too busy to install rust, so switching renderer might be even a bigger problem, since e.g. rsvg also depends on rust. So we might end up staying with librsvg, because it is the easiest way to go, independent on the result.