Open jimjam-slam opened 1 year ago
I don't think this is something we control in the R package. You may have to ask this upstream at the librsvg repo or maybe we can ask @federicomenaquintero.
Basically the R package calls cairo_svg_surface_create_for_stream
and then rsvg_handle_render_document
to render the svg back to an svg output stream. So somewhere they changed something.
The Windows binaries use cairo 1.18 and the MacOS binaries still use cairo 1.16. So if the same problem happens on both win and mac, then issue is probably not a regression in cairo, but a change in librsvg.
Cairo's SVG surface creates pretty horrible SVG documents :smiley: I haven't read its source code to see exactly what it does, but there's a lot of masking and compositing done by hand, and I don't quite understand it.
(That said, librsvg should be able to render Cairo's SVGs just fine - if it doesn't, it's probably a bug.)
However... are you taking SVGs and then rendering them with librsvg/cairo again to SVG? What's the reason for that?
@federicomenaquintero With the {ggflags} package, we ingest SVG flags on package build to store internally in the package, then render them in ggplot2.
For the build process, we were previously running the flags through grConvert::convertPicture()
to ensure they were Cairo-compatible, before storing them with grImport2::readPicture()
. But grConvert
is no longer maintained, so we're switching that out for rsvg::rsvg_svg()
, which is maintained and uses the same underlying library (librsvg).
When the plot is created, the user could render out to a raster format like PNG, or they could render back out to a vector format like SVG.
Just a follow up from #41 here regarding the circular masks in our flag SVGs:
The flags are quite a bit larger after processing—about 15-18 KB each, compared to less than 1 KB before processing. That's mostly because the mask (a black circle) is being base-64 encoded.
For example, in
au.svg
, here's the mask before processing with{rsvg}
:And here it is after:
It could be that this is required on Cairo's side for rendering in R and is hence a wontfix, and it's not really a problem as far as our package is concerned (except for folks rendering all the way out to SVG, perhaps), but it does blow the size out quite a lot!