translation of a set

[Strepsil]

I had some code that worked with 1.5.2 but is now broken in 2.0

I've added a circle to a set, and then translated that set - the
'cy' / 'cx' attributes of the circle used to update as the set was
translated, whereas now they don't change

here's an example to demonstrate:

var st = paper.set();
st.push(paper.circle(10, 10, 5));
st.translate(20,0);
alert(st[0].attr('cx'));

In 1.5.2, this would report "30", whereas in 2.0 it's still "10"

Have I missed something in the documentation about this change?

Thanks,
Tom.

[Ed Davies]

On Nov 10, 2:48 pm, Strepsil <strep...@gmail.com> wrote:
> I had some code that worked with 1.5.2 but is now broken in 2.0
>
> I've added a circle to a set, and then translated that set - the
> 'cy' / 'cx' attributes of the circle used to update as the set was
> translated, whereas now they don't change
>

> ...

>
> Have I missed something in the documentation about this change?

In the 1.x versions transformations were a mess: some updated the
object whereas others applied a 'secret' transformation which was
applied to the object's properties 'after the event'. There was a lot
of confusion because of effects like a translation applied supposedly
after a rotation caused the rotation's centre to change. A big change
between 1.x and 2.x, needing the change of version number to signal
lack of backwards compatibility, was to tidy all this up.

Now, at least as I understand it, the object properties are left
untouched and a single composite transformation is applied at 'display
time'. This is much simpler to understand.

As to the documentation, yes, the descriptions of Element.translate
are different to reflect this change:

1.5.2: "Moves the element around the canvas by the given distances."

2.0: "Adds translation by given amount to the list of transformations
of the element."

[Jedateach]

So what do you do if you want to adjust the element position, and not with a transformation matrix?

[Ed Davies]

On Dec 8, 2:30 am, Jedateach <jer...@burnbright.net> wrote:
> So what do you do if you want to adjust the element position, and not with
> a transformation matrix?

You call Element.translate or Element.transform for which you don't
have to worry about a transformation matrix. Presumably Raphaël will
combine that translation effect into its transformation matrix but
that's mostly¹ an internal thing.

¹ I wrote "mostly" because you seem to be able to get an element's
matrix via its "matrix" property but I can't see any documentation for
that.

[Jedateach]

I'm working on a problem where I need to modify the coordinates of a path, and not the transformation matrix. Ed, you're right that the matrix is updated when you call transform or translate, but in my case, I want to adjust the original points of the shape.

I'm hoping for a solution where the transformation can be 'baked' into the coordinates.

[ElbertF]

In that case you need to loop through the set and update each element individually (e.g. circ.attr({ cx: 10 })). Why couldn't you work with translations though? Visually it makes no difference.

[Jedateach]

Thanks for your reply Elbert. I think it will help if I explain the problem I'm trying to solve.

I'm building a t-shirt designer, where you can add text, shapes, and images to a garment to submit for printing. Each element can be scaled, rotated and dragged around a printable area in the designer.

Adding text is where I'm facing the problem. I need to use custom fonts, so that means using the Raphael paper.print function. As you likely know, this produces a set of paths. Since Rapahel 2, these paths are positioned using a matrix transform. Moving, dragging etc is also done by the matrix transform, so if you try to transform yourself, every character repositions relative to your chosen translation according to the original coordinates.

I've thought of a couple of ways of solving this:

• Store the original transform in each path (character) and do a pre-transform every time a transform of the set is done.
  
• Update the path coordinates so they sit nicely, relative to 0,0...and can then be transformed freely. (the option I'm discussing)

PS: thanks for your work with the FreeTransform plugin...I've been referencing it to figure out the implementation of this tshirt designer.

[Jedateach]

Here's my work in progress: http://jsfiddle.net/jedateach/4HnN9/6/

[ElbertF]

I'm not entirely sure what to issue is. Perhaps try explaining it like I'm an 8 year old. :) In your jsFiddle I don't see any issues with the translation, the shape looks exactly the same without it.

[Jedateach]

"The text is all bunched up" - my 8 year old explanation :) This was the first problem I noticed when I switched to Raphael 2

Do you see the red text on the jsFiddle? - that is the result of a transformation on the set of character paths. It should look like the (original) black text once I've finished with it.

[ElbertF]

That seems to be the result of concatenating paths, not transformations.

[Jeremy Shipman]

Yeah, that's right. I'm just trying different options to figure out
what will be the best solution.

I'm guessing you haven't come across someone trying to do this before.
You appear to be a forum regular, so I thought I'd ask. Plus, I'm
guessing some users of FreeTransform plugin will want to transform
custom text...so the problem could come up eventually.

[ElbertF]

You're drawing the path for the individual letters on top of each other. You can treat them as separate paths:

http://jsfiddle.net/X6YNm/1/

The issue isn't with transforming paths but with converting custom fonts.

[Jedateach]

Just to update:

I ended up storing the initial transform for each printed character. Every time the transformation is updated, the stored initial transforms are all applied, then the new transformation information is applied.

I have noticed some lag for longer strings, so I might try improve performance by combining all characters into a single path.