not a solution, but you can just write
getLocalBounds().toFloat() instead of that Rectangle line.
not a solution, but you can just write
Thats’a a nice hint about getLocalBounds().toFloat(). However, I think I’ll be able to work around the different scaling of the svg drawables that came up after the update by simply applying a transform to resize them back to the size they were meant to be displayed. But I don’t know what to do to get the text embedded in the svgs back that was definitively rendered before the update.
Just to be double sure, I just picked the first .svg file with some text on it that wikipedia gave me:
If you drag this into the Projucer window, the forms will be displayed correctly, but no text is displayed here too. So @jules this really seems to be a bug. Would be really great if you would take a look at the reason for the text issue
Can you give me a link to the actual SVG file you tried, that page has a lot of stuff on it.
Here is a direct link: https://upload.wikimedia.org/wikipedia/commons/e/e9/SVG-Grundelemente.svg
Thank you, I thought I would have pasted the direct link…
The example didn’t specify a font-size attribute for the text, and the juce parser was just defaulting to 0 so you couldn’t see the text.
I’ve modified this now so that it uses 15 as a default, but that’s not really a “fix”, as the behaviour for an unspecified size is (as far as I can tell) undefined. If you’re using real SVG text in your app, you really should make sure it contains the correct size.
Okay, you are talking about the wikipedia svg that had no font size, right? But if I take a look into the xml content of my level-meter image I find something like
style="font-size:2.11666656px;stroke-width:0.26458332"> 0 dB FS</tspan></text>
I’m not deep into the svg-standard, but to me it seems like there is a font size specified (2.11666656)? So maybe even if the unspecified font size was the reason for the wikipedia svg not to be drawn, this can’t be the problem with the level meter, which’s text was drawn in a correct size before the update, or am I wrong here?
Anyway thank you a lot for your patience with this issue until now. As a temporarily workaround, I now converted all text of the svg to paths, furthermore I got the scale working again. So currently my GUI is up and running again for algorithm development
2 pixels is unreadably small for a font unless you’re scaling the whole thing up…
Just to add some info. Since SVG is primarily designed for the web, the default font-size is 16px. So maybe it would be a good idea to render text that doesn’t specify a font-size with the default of 16px. Than it will look the same in the browser as in JUCE.
Fair point, although I used to scale it up trough RectanglePlacement::stretchToFit which looked good in JUCE 5.0.x.
Now I don’t know why the font size is so small there. I didn’t create those svgs, but I know that the creator (who is no professional graphic designer) put them together with Inkspace. So I downloaded Inkspace to see how it looks like in the editor it was created with:
As you see, in Inkspace the font size is set to 6pt - so I don’t know why this gets translated to 2.11666656px
In the Mac Finder preview area the svg file generated by Inkspace is very tiny, but it obviously displays the text:
In the Producers preview, its even smaller but without the text:
Now I thought that maybe Inkscape just generates some none-standard svg files, so I downloaded the 7 day trial version of Adobe Illustrator. If I open the image with illustrator, it looks like this:
Illustrator interprets the font size as 8pt, chooses a different font (probably because there is no actual font specified in the svg) and doesn’t display the grid above the level bar for some reasons.
Now, re-exporting the image as svg through Illustrator generates an svg-file that looks like this in the Finder’s preview:
It is displayed as small as the original version, displayed WITH text and WITHOUT the grid. And obviously with a lot smaller file size.
In the Projucer the Illustrator-Version looks like this:
A lot bigger than before, with the grid (why?? ) and with all text - except for the first “0 db FS” line. A look into the underlying xml now shows a completely different description for this text section:
<text class="cls-8" transform="translate(18.13464 8.08046)"><tspan xml:space="preserve"> 0 dB FS</tspan></text>
I don’t know if all this made things more clear of if this just confuses everything even more. At least I now know that svg seems to have so many options of describing the same thing in a different way that maybe no svg parser may cover all edge-cases.
I think, if my audio algorithms are up and running, a serious gui re-design, maybe with the help of someone who’s better at designing will have to be done. So the last question remaining now is:
What software should be used to create 100% JUCE-compatible svg images? Is there any free or open source tool you can propose or should I just pay for Illustrator and everything will be fine?
If you using text in a svg, simply convert to a path (inside illustrator or whatever you use). So you can be sure that it will look always the same on all platforms.
There are a few more rendering issues with SVG. This shows the latest JUCER side by side with IE. Internet Explorer renders it correctly. It appears to be a problem related to circular gradients. Hope this helps!
Here is a zip file with the SVG files inside: ftp://ftp.acoustica.com/Temp/Juice_svg_issues.zip
I gotta say, I’m using SVG almost exclusively for our assets, and I update JUCE whenever a new version is available (and honestly, about half the time, I’m deploying from the dev branch), and I haven’t run in to any of these problems.
I haven’t yet run in to a situation where what I made in Illustrator wasn’t exactly what I got in JUCE. Don’t know if this is helpful in the context of the above problems, but here are my Illustrator CC export settings, for use as a known working control case:
Thanks for the quick reply! I’ll check out the illustrator export options. Maybe it’ll help - but, as you can see, the SVG is not rendered properly in the latest JUCER itself.
I had a look at your SVG, and that’s not a radial gradient at all. It’s an embedded image (which is, in point of fact, circular, albeit somewhat larger than your artboard) that has been beat in to submission with a clipping mask.
Not to put too fine a point on it, but that’s just about the worst way to skin that particular cat. It is a way, but… What you’re seeing in the ProJucer is the actual embedded image, which is larger than the artboard. This isn’t really JUCE’s fault; the asset isn’t really JUCE-friendly.
Here’s the same thing, in a flavor that works.
(Also note that your 0,0 is in the lower left-hand corner; I didn’t change it to the upper left-hand corner, but that would obviously make a lot of sense given the nature of JUCE’s understanding of the Cartesian plane. Obviously, it doesn’t really matter as SVG is a relative system, not absolute, but it keeps things tidy.)
This is the right answer.