Closed tdindorf closed 11 months ago
I see a solution is to translate(), not move(), as described in issue #1110... I wonder why the change?
This was done to separate transforms from simple movement. Now you can rely on the fact that a move command will move the bounding box of the object as well (which is not the case if you transform an object). You can always explicitly use transform if you need to without any magic involved.
It's still a bug though so let's have a look.
So I attempted a fix but use-elements are just too much between groups and real element with how they behave. One important thing does not hold true for them: If you move them, their bounding box is not where you just moved. The current code abstraction however expects that. I will label this as wontfix for now and close it. Maybe we can figure something our for the next major version
Please have a look at the example https://codepen.io/tdindorf/pen/OJmBjZO
The one-but-last action, groupM.dx(-rS/2, 0) is the issue.
The result looks fine in 2.7.1, but not in 3.1.1: use() elements previously added to group groupM are drawn incorrectly (in 3.1.1) when the group is moved, be it using x(), dx(), cx(), move(), or dmove().