Ouch. Major headache.
Assume that the transformation is always in order:
translate(x,y) scale(sx, sy) rotate(t, cx, cy)
As stated, we're given cx, and cy:
transform="translate(20, 20) scale(3,3) rotate(60, 2, 2)"
At this point I've dragged the element some unknown amount. Although translate says (20,
20), I know this is not correct because I've also scaled and rotated.
Say the user drags and drops the element again. I can't just manipulate the translation because
I've rotated and scaled around a center point.
At this point, I need to "reverse" the rotation first, extracting it from the transform.
Then I need to "reverse" the scale as well, extracting it. What I'm left with is the amount
I've translated (dragged and dropped) by, correct?
Another question, in Java how can I change a transform attribute into the 6 matrix values?
In your example, do you compensate for the fact the element is rotated around the center
point? What about scaling around a center point? The amount that scaling effects is centerX
* (scaleX  1.0); I'd have to subtract that from the original translation as well to find
out exactly how much I dragged and dropped...right?
Michael Bishop
________________________________
From: Andrew Plotkin [mailto:erkyrath@eblong.com]
Sent: Thu 6/1/2006 2:10 PM
To: batikusers@xmlgraphics.apache.org
Subject: RE: Extracting information from a transformation matrix
On Thu, 1 Jun 2006, Bishop, Michael W. CONTR J9C880 wrote:
> All right, this is great information. I need to sit down and work
> through it with my SVG Matrix algebra examples in front of me. I do
> have a couple of questions:
>
>  Assuming I already have the center poitns, I could derive all the
> values I wanted right? The rotate(t, x, y) command is a shortcut for
> translation if I remember right. It's short for translate(x,y)
> rotate(t) translate(x,y) isn't it?
Yes.
If you already know the cx and cy, you can work everything out, yes. Let
me take a look at my example...
<ellipse id="sall" transform="translate(4,4) scale(3) rotate(60,1,2)"
rx="1" ry="2" />
cx,cy = (1,2) (we know this in advance)
translate=(10.69615268,4.401909828)
scale=3
rotate=60
The scale and rotate values are correct. We just need to fix the
translation.
(This is where we start applying some Experimental Mathematics. Which is
to say, I'm going to rearrange the equations until the right answers come
out. :)
Scale and rotate the cx,cy vector by the values we've worked out. (We're
converting degrees to radians now.
newcx = scale * (cx*cos(rotate*pi/180) + cy*sin(rotate*pi/180))
= 3 * (1*cos(60*pi/180) + 2*sin(60*pi/180))
= 6.69615241552696
newcy = scale * (cy*cos(rotate*pi/180)  cx*sin(rotate*pi/180))
= 3 * (2*cos(60*pi/180)  1*sin(60*pi/180))
= 0.401923908261826
Then to work out the original translation values, take the values above
and subtract (newcx, newcy)
(10.69615268,4.40190982)  (6.69615241,0.40192390) = (4,4)
>  Does the order matter? In the app, you can scale, rotate, and
> translate in any order.
Yes, the order matters. If you translate after you scale, you'll have to
unscale the translation values (divide them by the scale). If you
translate after you rotate, you'll have to unrotate them (apply some more
trig). Go through some examples and it should be obvious.
The order of scale and rotate doesn't matter. (As you can see: rotating a
shape and then scaling it produces the same result as scaling it and then
rotating it.)
Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't thrown you in military prison
without trial, it's for one reason: they don't feel like it. Not
because of the Fifth Amendment.

To unsubscribe, email: batikusersunsubscribe@xmlgraphics.apache.org
For additional commands, email: batikusershelp@xmlgraphics.apache.org
