On Thu, 25 May 2017 13:01:33 +0100 Mark Crutch <markc@...2744...> wrote:
From the very page on MDN that you linked to:
*Warning:* SVG 2 replaced the SVGMatrix interface by the more general DOMMatrix https://developer.mozilla.org/en-US/docs/Web/API/DOMMatrix and DOMMatrixReadOnly https://developer.mozilla.org/en-US/docs/Web/API/DOMMatrixReadOnly interfaces.
Thanks for catching that. It's good information. When it's time for me to target SVG2, I'll switch to DOMMatrix and DOMMatrixReadOnly.
The APIs are not exactly the same, but do appear similar so should probably be able to achieve the same result. Maybe. As SVG 2 is new and not exactly a popular target for the browsers vendors, however, I would stick with SVGMatrix for better support - it may be deprecated, but it's unlikely to be completely removed for quite some time to come.
Thanks Mark!
I was noticing that Mozilla Developer page was the only one asserting the deprecation. Everyone else (and that would be maybe 4 pages, because all this stuff is so horrendously underdocumented) acts like SVGMatrix is *the* way to read translations. I was beginning to doubt the Mozilla developer page, given that my use of SVGMatrix worked perfectly on Firefox, Chromium, Palemoon, Qupzilla and Surf. The SVG1/SVG2 distinction makes it make sense.
Of course, if you can be certain that the transform attribute will only ever contain a single translate(), you could just do some simple string manipulation instead:
screw.getAttribute("transform").slice(10,-1).split(",");
The preceding is a less confusing version of what I previously termed "a crazy train regex kludge method to read a translate".
I'm sure there are caveats about coordinate systems that mean this won't work in the general case, but it might be worth a try.
The general case is *very* difficult to deal with. Any element can have multiple transforms: An array of transforms. And order counts unless only mathmatically associative operations are done in those translations. Each transform can have multiple parts: rotations, skews, translates, whatever, and there can be multiples of those. Once again, order counts. Each containing container can have its own transforms, and you need to know how high up the hierarchy to go to achieve a specific goal. I'm not smart enough to do all of that.
The special case I'm working on is deducing x,y coordinates for multiple instantiations of a group I've created and then copied multiple times in Inkscape. Such groups' composite members all have the same dimensions and positions, with location differences determined exclusively by the group's "transform=translate(xoffset,yoffset)". My challenge was to calculate a layer-coordinate location of a group by adding its transform offsets to the x and y of one of its atomic contained entities (in this case a circle).
Because I'm the guy who made the group in the first place, I can be sure it has only one transform containing one translate and nothing else.
Thanks for your help!
SteveT
Steve Litt May 2017 featured book: Twenty Eight Tales of Troubleshooting http://www.troubleshooters.com/28