Kenneth Evans

After sleeping on it I had already decided to convert the text to paths in Inkscape. This seems the most robust solution, does not involve kludges, and has the advantage that there are no fonts that may not be on the user's computer. That was easy to do, and it seems to work. Thanks for all the help. I also learned some things. ?

@OSUblake, Yes, it looks like it. Why not just do that on the text elements. That is similar to what Zach did and what I have been working on. Also, you only did rotation. There is scale, and the horizontal ones have to be fixed, too. I have been writing something to parse all the SVG elements and fix the text ones doing something like what you both did. That requires extracting the rotation, scale, and translation from the matrix, which I can now do. It got late. So it looks positive it can be made to work. Thanks.

@OSUBlake That isn't the problem. That article is about removing transforms on the g element. Mine doesn't have a transform on the g element. The problem is worse than I said before. I had decided to just not use transformOrigin on the rotated text. However, that makes the other problem more noticeable: The horizontal text gets moved from its original position. I modified the CodePen to: Have an if(true) around the timeline stuff to make it easy to see what happens with that compared to the SVG alone. I also removed the tspan stuff from the HTML. It doesn't change the behavior but makes the HTML cleaner. To see the difference, run it with true, then run it with false. You can see the text jump. We are sort of down to GSAP doesn't play well with SVG text. In particular, from() doesn't return you to the original layout if you use transforms. However, maybe the solution in the CodePen Zach showed is a way around it. I'll look into that.

After more study: The x and y values are what they are because the matrix is rotating -90 deg about the viewBox origin. It needs a big swing to do this, so the bounding box starts at those values, y="88.710289" x="-57.960464" in a viewBox that is 100 x 60. After thinking about it I believe GSAP is, in fact, not handling matrices, and possibly any initially rotated elements, correctly. The telling argument is that from() is not returning to the original values. There is also the fact that if I use x and y values that work in GSAP, then they don't work outside of it. There is no mention of matrices in the CSSPlugin doc. They don't seem to have been thought about, or at least implemented. I would guess that it works when transformOrigin is not specified because it leaves things alone in that case, and the SVG transform works as it should. My conclusion (which I'm willing to change) is that GSAP doesn't play well with matrices, and the solution is to not use them. In my case presumably the matrix could be replaced with a scale and a rotate. I'm not sure how to get Inkscape to do this, but [also presumably] I could do the math and do it manually. I would, of course, be happy if I am wrong, and there is a way to handle this situation in GSAP.

Zach, Thanks for the detailed help. The reason for using Inkscape is that it is easy to design and line things up there. I am interested in animating SVG, so using what you get from the SVG file would be preferable. Your method would work in simple cases, though. I have determined the problem is that the vertical text has a negative x (y="88.710289" x="-57.960464"). I don't know why Inkscape did that nor why it works normally, It looks like using transformationOrigin causes something to wake up and use that. I can fix it by setting y="73" x="76.5" (determined by trial and error). I did it in both places. It now works with GSAP. But it doesn't work if I don't use any animation (comment out the timeline calls). I will try experimenting with the tspan as you suggested, and try to figure out what is happening. I don't mind taking things out of the SVG, but I don't want to have to change values like x and y.

Ok, I found the doc: https://greensock.com/docs/v2/Plugins/CSSPlugin It says the default should be "50% 50%", so leaving it out should be the same as including it. But it isn't. I changed the text to red and the opacity to 1 so I could possibly see where it actually is. I haven't found any combination of parameters where it is visible at all (except leaving out the transformOrigin). So I don't understand what is happening. BTW according to getParameter "scaleX=" "0.9509" "scaleY=" "1.0517" "rotation=" "-90" so I got the signs wrong. (Apparently rotation is in the clockwise direction, rather than what it usually is in math.) I'm learning. ?

Zach, thanks for the detailed reply. Ok, I see the ease:Back.easeOut is changing the opacity in the example. The better statement is that I can't see any effect, rather than it isn't working. I want it to bounce, and that would seem to require a transform of some sort (i.e changing y). The problem is that it is a matrix transformation which has both a -90 degree rotation and a scale: transform="matrix(0,-0.95087276,1.0516654,0,0,0)" So the question is how to determine transformOrigin to use in GSAP. "50% 50%" is supposed to be the center of its bounding box, I believe. (I haven't found transformOrigin in the docs.) I don't see why "50% 50%" doesn't work. The -90 degree rotation should not affect the center of rotation. So how do you do the math to determine the percents that GSAP wants. (I can do the math to figure out the scale, knowing it is a -90 deg rotation. Actually it looks like sy = -.95087276 and sx = -1.0516654. ) The scale is near 1, so I would expect it to be "approximately" right with "50% 50%" though. In reality, you don't see the text at all. Also timeline.from() is supposed to return to its original state. Why specifying a transformOrigin would affect its final state is not something I understand. I also don't see why a transformOrgin would affect opacity one way or the other either (there is no transform), but empirically it doesn't work unless I remove it. To be clear, I am not saying GSAP has an error. I might say it is unclear to me how to use it in this case, however. Thanks.

Thanks Zach, but the white text is not the problem. It is on top of the green box. And I would still have the problem if it weren't white. I have simplified what I actually want to do. I was using another ease and changed it to this for the example. I appreciate, though, your information that there is a better way to do none. And I guess I could just have left it off. I need the transform, because I also want to translate and rotate. However, taking it off fixes the problem. But then rotate does nothing and also ease:Back.easeOut does nothing. Possibly I need a different transform, but at the moment I don't know how to determine one. BTW I have looked at x, y, and rotate before and after the tween. They are the same, so I don't see what the transform is doing. Also it didn't hurt the horizontal text. I looked at the link for trying to fix it in Inkscape. I will work on that; however, I would like to understand why it is not working as is. I have a question about the CodePen. If I change it on CodePen will it change in this topic, or is this a copy? (It doesn't look like it is.) I'm new to CodePen, too. ? Added later: I looked at the Inkscape fixes. Those seem to be to remove a transform for a group (g element). My g element doesn't have a transform. I think I need to learn how to do it right in GSAP. Thanks.

I am new to GSAP so this issue may be owing to my ignorance. I am trying to animate some items in a logo, including vertical text. gsap.from doesn't work for the vertical text as shown in the CodePen. I am using an SVG created in Inkscape. I have removed most of the unnecessary things, but the text is still somewhat complicated. Sorry. I am unsure what is non-essential. If you comment out the timeline calls in the Javascript, it displays correctly. There is also a problem with the horizontal text. It is not in the same position as it is with the timeline calls commented out (just the SVG image).