My investigations on this have led me to the following conclusion:
For precision positioning, don't use the label or pin options.
And for that reason, I'm heartily recommending wh1t3's solution.
Nonetheless, it can be illuminating to see why the code is being particularly stubborn (and it'll also show why there's the strange "skip" when you vary the angles, which baffled me for a long time). To understand what's happening, you have to understand what happens when you pass a pin
option to a node.
TikZ figures out what angle you want the adjunct node to be at, via some magic that involves the specified angle, whether or not it is absolute, and something additional involving the transformed shape
key.
TikZ then sets a coordinate at a certain distance from the centre of the original node at that angle. (Note that this is from the centre of the original node.)
It then figures out the most appropriate anchor for the label node. This depends on the angle specified (and I think it depends on the absolute angle, not the relative angle - but I may be wrong there). What is particularly interesting about this is that there is a high probability that the resulting angle will be a corner angle. For example, the angle has to be between 87 and 94 degrees to get the anchor as south
.
TikZ then renders the label node, at the given coordinate, using the determined anchor.
For a pin
, TikZ then draws a line between the centres of the two nodes, but stopping on the boundaries (exactly as if you had written \draw (a) -- (b);
).
Putting all of that together, we see why we get such strange behaviour. For example, change the angle from 86 to 87 results in the anchor of the label flipping from south west
to south
, whereupon the centre of the node jumps by about half the text width. This leads to the resulting line changing a lot.
Now, for vague "label this node at an angle of 60", this level of automation is what you want - these decisions are mostly right most of the time. But if you want precision engineering, they can get annoying.
Annoyingly, the manual suggests that the major problem (which is the choice of anchor for the label) can be overridden. However, my experiments have failed to produce a successful high-level way of doing this. I have, naturally, come up with an Extreme Hack which solves the problem. The fact that I had to resort to Extreme Hackery led me to my aforementioned conclusion.
What you want is to be able to specify the angle of the label and then have the resulting edge drawn with that angle in mind, not between the centres. There are two ways to accomplish this by subverting the above:
Ensure that the centre of the label node is used as the anchor. Then the centres of the two nodes will line up along the original angle and the resulting edge will be drawn correctly.
Draw the resulting edge not between the centres of the nodes but between the anchors that have been used in positioning the label.
I prefer the second, but couldn't get it to work. So I present a solution based on the first. For this to work, we merely need to override TikZ's choice of anchor. The anchor is computed in a command called \tikz@auto@anchor
and this is used to set a macro \tikz@anchor
. So we temporarily disable \tikz@auto@anchor
and explicitly set \tikz@anchor
. A side effect of this is that the label isn't positioned as far away as it used to be so we need to increase the pin distance
(because the label is now anchored at its centre instead of on the boundary).
Here's the code:
\documentclass{standalone}
\usepackage{tikz}
\makeatletter
\tikzset{reset label anchor/.code={%
\let\tikz@auto@anchor=\pgfutil@empty
\def\tikz@anchor{#1}
},
reset label anchor/.default=center
}
\makeatother
\begin{document}
\begin{tikzpicture}
\draw (0,0) -- (90:2.7) -- ++ (-13:12)
node[shape=rectangle,pos=0.6,sloped,above,draw,pin={[pin edge={thin,black},reset label anchor,pin distance=.7cm]270:$mg\cos\theta$}]
{5kg} -- ++(0:-11.6);
\end{tikzpicture}
\end{document}
and the picture:

And I remind you that although the code looks quite simple, it is Extreme Hackery and should be used only with Extreme Caution. Use wh1t3's solution in Real Life.
(NB I used Ryan Reich's trace-pgfkeys
package from How do I debug pgfkeys? a bit in figuring out what was going on here. Very useful.)
sloped
applied also so that is why it is where it is.$mgcos \theta$' as
$mg\cos\theta$` ?sloped
and see what that it is at 270, and yes 180 should be parallel to the slope.