hi thomas, I really apreciate this forum thanks to people like you. Very complete answer. and now my code works. But actually, I don't know why (typical pattern as newby user). I'll have to read and read again your mail...
I have followed your 3 points: [1] Of course, each initial point is in each element coords. I did it exactly what you said [2] I took the parent's screenCTM (wishing the parent is a svglocatable) [3] I keep using concatenate for the translate I have attached the new code. Do you think it is worthin I add it to the how tos? On Tue, Mar 16, 2010 at 10:48 AM, <thomas.dewe...@kodak.com> wrote: > Hi Hodac, > > dao <dao.ho...@gmail.com> wrote on 03/15/2010 06:35:39 AM: > > > > I am a little bit confused with those coord conversions, etc... I > > suppose this is a piece of cake for you guys. Could you tell me what's > wrong? > > There were three significant errors. The first is that your code > assumed that the same local translate could be applied for each of > the children. This doesn't work you need to calculate the local > translate matrix for each child separately. I would suggest remembering > the start point in beginMove, then in 'move' you need to current > point so each "rect" can calculate it's transform. > > Second you need to be careful because as you change the translate > on the element the elements 'screenCTM' changes as well. To get > it to work you will either need to get the screenCTM of the parent > of the element you want to move (an approach I often use) and then > 'sandwich' the translate above the local transform (see next issue) > or store the screenCTM at the start of the move for use during each > move update. > > Third you used translate.concatenate but you needed to use > translate.preConcatenate. The way your code currently is you > want the resultant matrix to be the same as translating a point > by 'translate' and then by the pre-existing transform (remember > transforms are from child coordiate system to parent). This > is a little tricky however because if you use the parent's > getScreenCTM to calculate the translate then translate.concatenate > would be the correct method to use (you want the point to be > mapped by the elements local transform, then translated in > the parent's coordinate system). > > I should also comment that what you are attempting is the most > complex version of this. Typically you have a fair amount of > control over the documents you need to interactively manipulate > (especially complex manipulations like this). So I will typically > simplify things so I don't need to deal with all the complexities > you are dealing with. For example I'll ensure that the element > I will be manipulating the transform on has no transform initially. > > If I need to move multiple objects I'll move them into a > group and move the group (which means that all the objects I'll > need to move can't have parents with different transforms). > > > I can see that my solution does not work (as Thomas said) but the > > code of Jonathan does not work neither[...]. > > That code was good but it's not the complete answer for really > complex use cases. > > -- Dao Hodac
MoveIssue.java
Description: Binary data
--------------------------------------------------------------------- To unsubscribe, e-mail: batik-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org
