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.
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.
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.
There’s a difference between using the general graphics capabilities of JUCE, and the SVG graphics capabilities of JUCE. The SVG functionality is incomplete
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
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. https://dev.w3.org/SVG/tools/svgweb/samples/svg-files/
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.
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…
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.
