Complex SVG files fail to load properly

For some strange reason, more complex SVG files fail to load properly via the JUCE library. The effects of this problem show up in the Projucer, as well as in code that depends upon the JUCE library to load and display SVG files.

My ON button icons have a gradient on them, and subsequently the tools that my graphic designer is using (perhaps Adobe Illustrator?) outputs a 100kb file that will not load correctly in JUCE. But the OFF button icons have no gradient and are a 600 byte file that loads without any problems.

I have attached a screenshot of the ON icon in a browser vs the ON icon in the Projucer.

Did you managed to solve this issue?
I have the same problem with much worse results.

Here is the image i’m trying to load :

and this is how the image is loading in Projucer

The lack of radial fill on Mac made me decide to go with the large bitmap route, just to be sure of render capability and quality of final result, no matter the artwork style. I really wanted to to use SVG but they just kept failing for me.
BTW Antonis I don’t think you can include drop shadows in SVGs. Not when I tried exporting from Affinity Designer anyway.


I don’t think there are any plans to complete Juce’s SVG capabilities. I only use SVGs for very simple designs, especially those that do not include gradients of any kind.

is that a JUCE limitation or an OSX limitation? surely this can be done with OpenGL shaders, no?

It’s a Juce problem. Everything can be done with shaders, OpenGL or whatever is next because of the redaction. But that would mean converting the svg precisely, in a pixel perfect way - Good luck with that. Besides, that’s kind of off topic.

What do you mean by “radial fill”, juce::ColourGradient has a radial mode. Or is it not supported by the SVG Drawable?

There’s a difference between using the general graphics capabilities of JUCE, and the SVG graphics capabilities of JUCE. The SVG functionality is incomplete

Is there a definitive list of what features are missing from the JUCE implementation?

I think it also depends on what exported the SVG. The last time I used it I couldn’t export some squares properly, pretty much when I gave up :- SVG issue rendering simple rectangles

1 Like

maybe this needs to be looked at again?

There’s no official or well-defined list of what’s missing in the SVG implementation, nor other popular systems like XML and JS.

Time to spreadsheet like a madman?

The other part is the lack of SVG tests; visual inspections, unit tests, and performance… For example, W3 provides a nice variety of specific test files that should probably be thrown at JUCE to help outline what’s missing, what works, what works well, and what doesn’t work/work well.


Nice site.
This is a fairly good acid test:

I do understand the hugeness of supporting the full SVG spec though.

That’s a pretty decent acid test for sure.

Yeah, this is by no means trivial in terms of implementation and support. Would be nice to see a list that can be prioritised though. Some features are certainly more useful than others, and I’m sure there are many niche ones that can be put back in the pantry instead of the back burner.

Is there an open-source implementation that could be used as a reference?

maybe this:


Cairo has an SVG parser, too:

sooooooo who’s gonna be the one to tag the juce team to get this done?

Whoever is local and knocks on their door hard enough is my guess.

It’s impossible to know what their priorities are and what kind of bandwidth they have to even approach this. It would have to be loud enough of a request…

1 Like

I think perhaps it’s better to have many people request something than for one person to “request loudly”. That way they look at it as a feature that benefits many subscribers and worth devoting resources to.

I was being sarcastic… Should have added /s I guess.