I got a new UI design for a plug in that has been designed with Adobe XD. It looks great and my designer exported the various parts of it as SVGs. The SVGs look great in the web browser as well. But rendered with JUCE they are full of all kinds of flaws and especially most shadows are not rendered correctly, some shapes are not where there are expected to be – seems like the SVGs exported by XD are full of things the JUCE parser has not implemented.
I planed to create a purely vector graphics based freely resizable user interface. However, with the way the JUCE SVG parser interprets the SVGs this is simply not possible. Before reverting my plans and moving back to a raster based user interface, I wonder if there are any suitable third party libraries that allow rasterizing my SVGs correctly without artifacts at runtime? A quick search revealed Skia but that seems like a massive dependency
Maybe somebody else faced a similar problem before as well?
Or, as another option, if the JUCE team wants to extend its SVG capabilities I’d be happy to supply the failing SVGs to them But I’m not sure if there are any plans like that?
I haven’t tried any third-party SVG libraries, but occasionally when JUCE is having issues with Adobe SVGs I’ve had success by opening the files in Inkscape and resaving them. It’s very hit or miss, but it might be worth trying.
Will try that as well! Interesting enough, former UI Designs from the same designer which he created with Illustrator instead of XD worked better, so it’s probably really some formating think or so. But it still seems that some kinds of shadows are simply not supported at all from the JUCE side
Thank you for that detailed response. To be honest, I have nearly no knowledge of SVG internals, so the details shared above seem quite cryptic for me at the moment
I’ll definetively try out svg-simplify, thank you for that link. However I’m not sure if learning SVG internals is the most straigtforward way for me to get this working? If all automated tools like svg-simplify and re-exporting from inkskape don’t help, I feel more confident and safe with adding a third party dependency with all its downsides than learning to read SVGs (and maybe coming to the conclusion that there are still problems issues with the JUCE renderer)
Note that if you do end up investigating and finding which missing functionality in JUCE’s SVG implementation you need, reporting it might be better in the long term. At least you won’t find yourself needing to fix two libraries
Totally agree with that. At the moment I’m indeed looking for a quick solution as the planned release is not too far away and this is a real blocker, but in the long term I might investigate whats wrong in the JUCE implementation and of course share my findings!
So I had a closer look at resvg. Built a quick JUCE wrapper around it:
I modified the Cargo build script to output a static library, as I’m not interested in installing dynamic library dependencies with my plugin if possible. On Mac this works quite well, while the static lib is quite large, the binary size stays reasonably small and all works smooth. And especially my SVG assets finaly look like they should
However on Windows I’ve run into more trouble with that. Seems that the rust compiler will always output a library compiled again the non-debug DLL runtime (like compiling with /MD) which leads to linker errors if the application/plugin itself is built with any other option. But I didn’t find any information on how to change that. @olilarkin As you suggested the library, did you already use it successfully on Windows and if so, how did you get this working? I have to admit that I feel quite more at home on Mac OS and as I said I’ve got no rust know-how, so this might be something quite simple