[Inkscape-user] SVGMatrix deprecated?

[Tavmjong Bah]

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, 25 May 2017 13:01:33 +0100

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
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
https://lists.sourceforge.net/lists/listinfo/inkscape-user