Today, I’m thrilled to present you with resvg_nif, an open-source project that provides Elixir bindings for the Rust-based SVG rendering library resvg. After initially exploring resvg via a port, I decided to take a plunge into creating native bindings for it.
SVG to PNG conversion:
:ok = Resvg.svg_to_png("input.svg", "output.png")
Resvg also allows direct handling of SVG content as strings:
To see Resvg in action, you can try the Livebook !
This NIF originated from my endeavor to create a system for generating YouTube thumbnails. After experimenting with various approaches using ImageMagick and libvips, I discovered that utilizing SVGs for conversion yielded the best results, simplifying testing in the process. The impressive support for fonts and SVG images offered by Resvg is strikingly similar to the rendering you get in a browser, making adjustments and testing much easier.
Something which is useful for complex drawings is to be able to determine the dimensions of text boxes. Resvg can be used to query the dimensions of SVG elements (in particular text elements). Maybe might be interesting to expose the query functionality? I won’t be usint that for my own projects as ExTypst fits my bill better, but it’s something to think about.
Cool library and great to see some bindings for the current go-to SVG renderer.
I’m curious about what issues you had with libvips (I maintain image which is ultimately built on libvips). I’ve not had any special issues with SVG rendering (although it currently binds with libsvg with plans to move to resvg).
Your work with image, and specifically the use of Operation.svgload_buffer(svg), was a significant source of inspiration while I was developing this library.
I encountered several issues with libvips / vix that led me to try alternative:
Windows Support: One of my primary requirements was compatibility with Windows. Unfortunately, as of the time of development, vix did not support it.
Font Loading with librsvg: I was unable to successfully get libvips to load my specific font.
SVG local file resolution: Another challenge I faced pertained to the svg element <image> in librsvg when resolving local files.
I found resvg to be more compatible with my requirements. Resvg allowed you to specify the :resources_dir, facilitating the resolution of images from this path:
Moreover, I found that resvg provided results that closely matched those from the browser. This aspect was particularly important to me as I heavily rely on the browser to create the svg templates and making adjustments.
@MRdotB, Thanks very much for the thoughtful response, really appreciate it. I agree with all three of your challenges with libsvg (under libvips) although I would like to try and debug a little further the font loading issues you had. Are you able to share your .ttf file for the font that wouldn’t load?
On the image loading part, typically Image would encourage composing images to achieve the result, but given your templating approach I can see why you want everything to be in an <svg> tag.
Also great to see more bindings for some good Rust libs too.
Amazing thank you @MRdotB!
The Livebook example needed {:resvg, "~> 0.3"}, to succeed and it got the NIF like charm! Congrats, I’m imagining Windows is not a top priority for the majority of image processors, but you managed to figure it out! Thank you!
@MRdotB I wonder if it’s possible to return the PNG directly instead of having to save it into the file? My use case is generating those images “on the fly” and sending them as a response in Phoenix Framework.
Great library, thank you! The only issue I noticed is that the text wasn’t loading on Linux unless I specified the font-family, but that’s related to resvg itself and not the Elixir library.
Unfortunately the underlying vix isn’t supported on Windows so if that’s a requirement then this isn’t the solution for you. Also it uses librsvg as the svg renderer, not libresvg.
Is your input a svg file or a svg as a string ?
If it’s a svg as a string there is svg_string_to_png_buffer/2
I did not implement svg_to_png_buffer but it should be easy.
Unlike what I’ve written above, my data visualization library is currently using Resvg instead of Typst due to serious performance problems when I try to use Typst to render visualizations with > 1000 elements/datapoints.
Currently I’m generating SVG files, and I use Resvg (with the query_all function) to get text dimensions. And also to render SVGs into PNG.
However, one often wants to export SVG as PDF or at least to publish SVG files with embedded fonts so that rendering is reproducible.
I’ve thought of the following:
Would you include functionality to render SVG into PDF using the svg2pdf crate? Or do you think it is out of scope for your library?
Regarding the embedding of fonts… Does Resvg provide a way of querying the SVG file for the fonts that are actually used so that one knows which fonts to embed?
If this is considered out of scope for Resvg, would you like to add the relevant NIF functionality to my Quartz package? This later option would be quite convenient because I might want to add further rust libraries for more calculation-intensive tasks.
Resvg does not provide pdf export so this is out of scope.
I did not found a way to access it out of the box in resvg but it’s in the data tree. So doing a filter by text node / uniq by font should work. This feature could be a useful addition to resvg_nif.
I don’t have much time to work on OSS this days I will maintain and review PR but that’s all.
Hey @MRdotB. I recently started playing with rustler and I wanted to check how did you annotate the functions with nif scheduler but It’s missing. Do you think it should include dirty_io when loading a file and dirty_cpu when processing it.
In my current use case, the execution of NIFs for creating small images is instantaneous, which is ideal. However, this might pose a problem when rendering large and complex SVG which is more cpu intensive. Flagging them as DirtyCpu is probably what’s needed.
It’s worth noting that this is my first and only experience with Elixir NIFs, so I’m open to further insights doc
Would you mind if I copied the resvg_code into my package so that I could tweak it for my use case? I agree with you that Resvg shouldn’t try to be too generic. I promise I won’t bother you with questions regarding the modified code. I understand if you don’t want slightly modified versions of your code in other projects, though.
Hello thanks for your last contribution,
