mapcairo.c: allow build with librsvg < 2.46 - #7462

thanks @ness31 Can you rebase this against main branch? (we can then backport it to branch-8-6)

@jmckenna done thank you

@ness31 I pushed a minor styling change into your PR here (to hopefully fix a failing automated test, regarding linting)

@ness31 - what is the rationale behind supporting librsvg < 2.46? Is it tied to a Debian stable version? Looking at the release tags the last 2.45 release was in 2019.

@geographika I'm building on Almalinux 8 embedding librsvg2-devel-2.42.7 package; otherwise I'll have to compile librsvg from source

Thank you @jmckenna
We've tested this PR by applying the patch and rebuilding MapServer 8.6 using the camptocamp/mapserver base image, but unfortunately the SVG scaling issue from #7430 still persists.

Our test environment:

Base image: camptocamp/mapserver:8.6-gdal3.12
MapServer version: 8.6.0
librsvg version: 2.58.0 (Ubuntu 24.04)

The issue remains because librsvg 2.58.0 is >= 2.46, so the code still uses the rsvg_handle_render_document() path which has the viewport sizing problem with some SVG symbols.

See #7430 for our test case with SVG samples and screenshots. We're currently using an LD_PRELOAD shim to redirect to the legacy rsvg_handle_render_cairo() API as a workaround.

We also tested this patch and unfortunately the scaling issue is not fixed when using a an up to date stack (Mapserver 8.6.5, librsvg 2.61.3, Ubuntu 26.04 LTS).

• using the code from this PR (compile path to use rsvg_handle_render_document vor librsvg >=v2.46) does not work with librsvg v2.61.3, both if the svg has a viewbox or not
• adaptinng mapcairo.c to always fall back to the legacy function rsvg_handle_render_cairo does work

So maybe using rsvg_handle_render_cairo could be applied as workaround until a better solution exists, as @linea974 and @ltclm are doing? Obviously this is not a long term solution as that function is marked as depreciated.
I can open a new PR if this is helpful.

@jmckenna could you maybe re-open issue 7430 as long as it is not solved?

Thanks @johanez. Yes it would be great if you could open a new Pull Request with a workaround.