7

Since I upgraded to PGF 2.10, some of my arrows drawn with to don't look right anymore. For instance, they are missing arrow-heads, and some other styles I applied to them have also disappeared. For example:

\begin{tikzpicture}
    \draw (0,0) to[->, line width=2mm] (3,1);
\end{tikzpicture}

enter image description here

I'm not getting any error messages nor anything relevant in the log file. This example compiles correctly with PGF 2.00.

mhelvens
  • 6,126

1 Answers1

9

Since PGF 2.10, arguments modifying path style no longer work when you put them after the to keyword. They should be put directly after the \draw command. Like this:

\begin{tikzpicture}
    \draw[->, line width=2mm] (0,0) to (3,1);
\end{tikzpicture}

enter image description here

All in all, this took me weeks to find out. For quite a while, I even downgraded to PGF 2.00 because my arrows didn't work.

I'm not sure if this is a bug in PGF 2.10 or if I was never meant to put these properties on to, and PGF 2.10 fixed the mistake. However, in the latter case, I would have expected an error message.

In any case, I advice you not to worry about it and just put these sorts of properties on \draw, which always seems to work.

If anyone has more information about this phenomenon, I'd be very interested!

mhelvens
  • 6,126
  • If I'm not mistaken, to path didn't have any options before so that's why TikZ could understand the options for example this also works : \draw (0,0) to (3,1) [->, line width=2mm]; So if it's not ambiguous, TikZ is smart enough to see that options are coming in, but here to also looks for extra options that are not necessarily related to the path drawing, hence the conflict. So it cannot throw errors since the code is legitimate. – percusse Sep 13 '12 at 13:19
  • Hm... No, to had options before, like in and out. That's basically the reason I was using to in the first place. – mhelvens Sep 13 '12 at 13:27
  • 4
    Yes, I didn't recall correctly. This is from the changelog by T.Tantau Changed scoping rules for to path operation: Options are now local. This may break existing code, but is much more consistent with everything else and removes other problems. – percusse Sep 13 '12 at 13:32
  • Ah, I finally have a definitive explanation. Thanks! :-) – mhelvens Sep 13 '12 at 13:33
  • But then.. wouldn't it make sense to get at least a warning when you provide options that make no local sense? – mhelvens Sep 13 '12 at 13:35
  • I think that would be a huge task since you have to classify what is locally effective and what is not. Especially if you are using custom styles such as ..to[mystyle] it gets quickly out of hand Besides you can use some of the keys both locally and globally . – percusse Sep 13 '12 at 13:41
  • Well, I won't go into language/library design with you. ;-) I feel like it wouldn't be so hard to detect whether a command had any effect or not, theoretically. But I don't know enough about the guts of TeX and PGF to make that judgment. Thanks for your answer! Let's close this discussion. – mhelvens Sep 13 '12 at 13:45