I have a bunch of SVG files that do not render correctly with Drawable::createFromSVG. What they have in common, is that a <use> XML tag (which references a path) includes x and y attributes. Those attributes seem to be ignored, as each path is drawn at the origin rather than (x, y).
This comes up in rendering SVG that represents multiple characters, each represented by its own path. Each character is described in local coordinates, and is meant to be translated to (x, y). I am trying to display math text rendered from LaTeX into SVG format. An example file is given below:
After some more fiddling, I found that the use tag works as expected when placement is done by supplying an attribute such as transform="translate(32 64)", whereas x="32" y="64" appears to be ignored by the SVG parser in <use> tags.
This could be worked around by pre-processing the XML, inserting transform attributes where needed.
Should the “x-y” attribute method for placement be supported in JUCE? It must be part of the official standard, and all LaTeX-to-SVG compilers I’ve found so far use this.
Here some more issues with the SVG parser! Just what you wanted to work on, I’m sure. I would love to contribute a solution if I was smarter and could comprehend the parser code. Feel free to point me in the right direction if you have a clue what’s causing the issue. Of course I’ll contribute the solution if I somehow find one.
The SVG parser generates artifacts for certain paths, two examples of which I have pasted below. These SVG’s are created by MathJax and render correctly in Chrome and Safari. This issue is unrelated to JUCE’s lack of support for x and y attributes in use tags, which started this thread.
Thanks. I started fixing the other one but it’s actually a total nightmare to implement correctly and I didn’t have time to finish. Will look at this one too when I get back to it!
For example, the minus sign I posted earlier reads like this:
<path id="theMinusSignProducedByMathJax"
d="
M 84 237
T 84 250
T 98 270
H 679
Q 694 262 694 250
T 679 230
H 98
Q 84 237 84 250
Z">
</path>
This path contains a T immediately following an M. From the specs, this should be equivalent to the following:
<path id="theMinusSignWhichRendersCorrectlyInJUCE"
d="
M 84 237
Q 84 237 84 250
T 98 270
H 679
Q 694 262 694 250
T 679 230
H 98
Q 84 237 84 250
Z">
</path>
That is, since the T does not follow any of Q, q, T, or t, the control point for the T should be the current point, which is the argument to the M. JUCE incorrectly assumes the origin for the control point there.
I hope this is enough info for you to fix the bug in a flash. If not, I’ll dig into the parser and try it myself.
Thanks, Jules! I took a look and it seems the two SVG’s from the earlier posts are still not rendered equivalently, although it looks better. It behaves as if maybe drawing a line from the arg of M to the arg of T, rather than inserting the equivalent of a Q, whose control point is the arg of M. I’ll see what I can do.
Hmm, I followed the SVG spec, and the example SVG I was looking at produced the same result in my renderer as the OSX preview did… If you want to suggest a tweak to the parser, please do!
Yes, I think the issue is rather specific to the way MathJax issues its SVG, so probably not relevant to many users. I’ll send you the diff when I find a solution.
For the use with x and y fields, I believe you can achieve what you need easily by first applying this patch https://github.com/soundradix/JUCE/commit/027c5ae0cd7e22dbcc2adeed8eacb198371a7292 which I made in SR’s branch to add transform field support to use clauses (which we happened to have in the SVGs made by our designer), and in parsePathElementWithTransform add code to check for the x and y fields. Though in the presence of both x/y + transform one should find out which of them should be applied first (i.e. scaling after x/y offset is different than scaling and then applying x/y offset)…
