Alternative SVG parser/rasterizer?

1

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 :grimacing:

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 :wink: But I’m not sure if there are any plans like that?

1 Like
2

this rust library is the best thing i have found, which uses skia to render.

you can build a static lib with c bindings, and rasterize into a juce image

1 Like
3

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.

4

Thanks @olilarkin, that sounds promising!
I have zero rust experience, but if all I need is compiling the C library from it, I guess I‘ll manage that :wink:

So I can build a static library with it that uses skia but has no runtime dependencies to skia as a shared library?

5

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

6

The best thing is actually mitigate the SVGs themselves or actually fix juce :slight_smile:

Here some things I have logged internally for us (we work around them by modifying the SVGs).

  • SVG alpha for <image> isn’t preserved. (usually your Illustrator/Adobe export would have a base64 image with alpha that JUCE ignore). <- shadow rendered too harsh ?

  • SVG styles (css) classes are being overwrite instead of appended.
    eg:

.class-1 { blah }

.class 1,
.class-2 { grrr }

So SVG wants .class2 to have { blah grrr } but instead it’ll just have grrr.

Last,
This is a useful utility made by @yairadix that designed to help some issues on the SVG side.

Again,
best would actually be to fix JUCE renderer.

btw,
advantage of JUCE renderer vs suggested binding:

  • smaller binary footprint
  • ‘some’ optimization. since the SVG calls will be translated to graphic ones. on OpenGL for example, some would benefit from being shaders. (some at least…)
5 Likes
7

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 :wink:

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)

2 Likes
8

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 :wink:

2 Likes
9

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!

2 Likes
10

Update:

Trying to simplify the SVGs failed :neutral_face:

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 :heart_eyes:

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? :smiley: 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 :wink:

1 Like
11

I also had trouble with that https://github.com/RazrFalcon/resvg/issues/201

If you can build a dll you should be able to link that whatever (but dlls are not much fun with plugins)

1 Like