Use resvg for svg conversion (before trying rsvg-convert)

[jgm]

@jgm would it be worth considering resvg as the first choice before rsvg-convert/librsvg when Pandoc auto-detects an SVG converter?

The reason I ask is that it seems to fit the constraints discussed here better than the other alternatives:

• unlike Inkscape, it is explicitly usable as a headless CLI/library for rendering static SVG files, so it avoids the GUI/CLI instability concerns raised above;
• unlike a browser/Puppeteer-based route, it is a small standalone renderer with no heavyweight runtime dependency;
• compared with librsvg, its own SVG support test chart currently looks noticeably stronger: resvg 0.45.1 passes 1520 tests vs librsvg 2.58.0 passing 1168;
• it is implemented in Rust, has very little unsafe, and aims for reproducible output across platforms, which seems attractive for a Pandoc pipeline.

The chart from the resvg project makes the comparison pretty clear:

Source: https://github.com/linebender/resvg/blob/main/.github/chart.svg

So maybe the default preference order could be something like resvg first, then rsvg-convert as fallback, at least for the output modes where resvg fits Pandoc's conversion path?

Would you prefer reopening this issue for that discussion, or should I open a new issue focused specifically on considering resvg and the SVG converter preference order?

Originally posted by @cesaryuan in #8176

[jgm]

Looks like resvg only converts to PNG, not PDF (like rsvg-convert).
So this is a big advantage of rsvg-convert. Hence not sure about this change.

[perennialmind]

resvg allows for other rendering targets, but leaves them to third party libraries. The relevant library with a focus on PDF would be krilla, specifically krilla-svg.