Hi all,
I have a bunch of groups of class "screw", each comprised of a circle screwhead and a smaller square in the center called a screwsquare. In every instance of "screw", screwhead and screwsquare have identical x, y, height, width and r dimensions. Each screw's position is determined by the screw group's transform=translate(xadjust, yadjust). This is done automatically by Inkscape, and furthermore, it's easy to set manually with:
myElement.setAttribute('transform','translate(xadjust,yadjust)');
The trouble comes in when you want to *get* that transform. Getting the transform is necessary when you want to move element whatever2 in relation to the location of screw1. Getting the translation is one of the worst documented things I've seen, but the concensus seems to be something like the following (for my screw case where the group has the transform):
=============================================================== function screw_coords(screw){ matrix = screw.transform.baseVal.getItem(0).matrix; var coords = []; shead = screw.querySelector('.screwhead'); coords[0] = shead.cx.animVal.value + matrix.e; coords[1] = shead.cy.animVal.value + matrix.f; return(coords); } ===============================================================
The preceding is ugly and fragile for a whole number of reasons, it's inobvious and horribly undocumented. But the real problem is it appears to be deprecated:
https://developer.mozilla.org/en-US/docs/Web/API/SVGMatrix
The preceding article says not to use SVGMatrix, and to update code as soon as possible, but remains mute on what you use instead. How the hell do you read a translation? It's a mystery.
The following article gives a crazy train regex kludge method to read a translate:
https://stackoverflow.com/questions/10349811/how-to-manipulate-translate-tra...
If anybody knows the proper secret handshake to read a translate in a non-deprecated, browser independent, non-kludgificent way, please let me know, perhaps with some URLs of docs for such a functionality.
Thanks,
SteveT
Steve Litt May 2017 featured book: Twenty Eight Tales of Troubleshooting http://www.troubleshooters.com/28
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.
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.
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(",");
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.
Mark
On Thu, May 25, 2017 at 11:55 AM, Steve Litt <slitt@...2357...> wrote:
Hi all,
I have a bunch of groups of class "screw", each comprised of a circle screwhead and a smaller square in the center called a screwsquare. In every instance of "screw", screwhead and screwsquare have identical x, y, height, width and r dimensions. Each screw's position is determined by the screw group's transform=translate(xadjust, yadjust). This is done automatically by Inkscape, and furthermore, it's easy to set manually with:
myElement.setAttribute('transform','translate(xadjust,yadjust)');
The trouble comes in when you want to *get* that transform. Getting the transform is necessary when you want to move element whatever2 in relation to the location of screw1. Getting the translation is one of the worst documented things I've seen, but the concensus seems to be something like the following (for my screw case where the group has the transform):
=============================================================== function screw_coords(screw){ matrix = screw.transform.baseVal.getItem(0).matrix; var coords = []; shead = screw.querySelector('.screwhead'); coords[0] = shead.cx.animVal.value + matrix.e; coords[1] = shead.cy.animVal.value + matrix.f; return(coords); } ===============================================================
The preceding is ugly and fragile for a whole number of reasons, it's inobvious and horribly undocumented. But the real problem is it appears to be deprecated:
https://developer.mozilla.org/en-US/docs/Web/API/SVGMatrix
The preceding article says not to use SVGMatrix, and to update code as soon as possible, but remains mute on what you use instead. How the hell do you read a translation? It's a mystery.
The following article gives a crazy train regex kludge method to read a translate:
https://stackoverflow.com/questions/10349811/how-to-manipulate-translate- transforms-on-a-svg-element-with-javascript-in-chrom
If anybody knows the proper secret handshake to read a translate in a non-deprecated, browser independent, non-kludgificent way, please let me know, perhaps with some URLs of docs for such a functionality.
Thanks,
SteveT
Steve Litt May 2017 featured book: Twenty Eight Tales of Troubleshooting http://www.troubleshooters.com/28
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
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
The relevant specification is CSS geometry but it is a work in progress. Note that it is independent from SVG 2 (which means that browsers will likely implement it even if they don't implement much from SVG 2).
https://drafts.fxtf.org/geometry/
SVGMatrix is defined in this document as an alias for DOMMatrix.
Tav
On Thu, 2017-05-25 at 13:31 -0400, Steve Litt wrote:
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
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
participants (3)
-
Mark Crutch -
Steve Litt -
Tavmjong Bah