3

I am having an issue when I use shift and rotate. In one case, the rectangle is being elongated down to the stopping point of the shift and rotate.

However, if I issue the same command in another case, the rectangle acts in the appropriate manner by rotating and shifting not elongating to the stopping point.

\documentclass[convert = false, tikz]{standalone}

\begin{document}
\begin{tikzpicture}
  \coordinate (O) at (0, 0);

  \filldraw[outer color = blue!75!pink!60,
  inner color = red!50!black!20, rotate = {-30}, shift = {(2, 0)}] (O) rectangle
  (.75, .5);

  \filldraw[red] (3, 0) rectangle (4, .75);
  \filldraw[red, rotate = {45}, shift = {(1, 0)}] (3, 0) rectangle (4, .75);
\end{tikzpicture}
\end{document}

enter image description here

I would like the elongated rectangle to behave as the red rectangle. When I issue a rotate and shift, I want the rectangle to do just that not stretch to the spot.

This stretching only occurs with objects placed at the origin.

Improve this question
5
  • shift is not moving the object, it is adding the shift amount to all explicit coordinates on the path. (O) is not an explicit coordinate.
    – percusse
    Aug 5 '13 at 18:23
  • @percusse why isn't that occurring when the object isn't at the origin?
    – dustin
    Aug 5 '13 at 18:24
  • 1
    @dustin: It doesn't have anything to do with being at the origin or not, it's using a node (O) that causes the problem, because nodes aren't transformed. You can either use (0,0) instead of (O), or you can apply the transformation to the node explicitly using \filldraw[outer color = blue!75!pink!60, inner color = red!50!black!20, rotate = {-30}, shift = {(2, 0)}] ([rotate = {-30}, shift = {(2, 0)}]O) rectangle (.75, .5);
    – Jake
    Aug 5 '13 at 18:28
  • @Jake are you going to post your answer?
    – dustin
    Aug 5 '13 at 18:42
  • Related question is Transform defined coordinates in TikZ where a few solutions are posted.
    – Qrrbrbirlbel
    Aug 8 '13 at 5:21
1

The transformations are not commutative. Consider the examples below;

\documentclass[convert = false, tikz]{standalone}

\begin{document}
\begin{tikzpicture}
\draw[style=help lines] (0,0) grid[step=1cm] (3,3);
\coordinate (A) at (1,1);
\fill[red,shift={(1,0)}] (A) rectangle (2,2);
\fill[blue,rotate=45,shift={(1,0)}] (A) rectangle (2,2);
\fill[yellow,shift={(1,0)},rotate=45] (A) rectangle (2,2);
\fill[orange,rotate=45] (A) rectangle (2,2);
\end{tikzpicture}
\end{document}

enter image description here

As you can see from the last orange box, (2,2) is rotated and becomes vertical but (A) doesn't. That's because (1,1) is still at the original place. It is the difference in a nutshell between coordinate transformations and canvas transformations.

This is one of the reasons why I stick to lower level PGF versions of transformations. Otherwise if you want to operate on the coordinate itself Jake's comment is the way to go.

Improve this answer
2
  • I don't think the problem is the non-commutativeness (is that even a word?), but the fact that the node (A) isn't shifted, unlike the (2,2) coordinate, which causes the stretching in dustin's code. Try replacing the (A)s with (1,1) in your code to see the difference.
    – Jake
    Aug 5 '13 at 18:35
  • @Jake Kind of. (A) is a fixed point in the canvas and the tranformations apply to coordinate calculations that uses \pgfvecx etc. so they are parsed. (A) doesn't get parsed but referred to. Was that a proper sentence?
    – percusse
    Aug 5 '13 at 18:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.