# How to give a name to \pic

I read instruction how to use \pic in PGF 3.0.0 manual, but description how to give names to \pic are not clear to me and given example generate error: "No shape named EmmaEmma-left is known."

Example in manual (pp. 255):

\documentclass[tikz,border=3mm]{standalone}
\tikzset{
seagull/.pic={
% Code for a "seagull". Do you see it?...
\coordinate (-left wing) at (-3mm,0);
\coordinate (-right wing) at (3mm,0);
\draw (-left wing) to [bend left] (0,0) (-head) to [bend left] (-right wing);
}
}
\begin{document}
\begin{tikzpicture}%\small\sffamily
\pic (Emma) {seagull};
\pic (Alexandra) at (0,1) {seagull};
\draw (Emma-left wing) -- (Alexandra-right wing);
\end{tikzpicture}
\end{document}


It's obvious that something is missing in above example. Please enlighten me, what I missed.

-

This is a work around rather than a solution. I wonder if this is a bug but my understanding of tikz is just not good enough to know for certain.

Apparently, tikz no longer likes something about the to operation here within the pic.

What tikz appears to be doing in the case of the \draw... to.. operation is doubling the prefix so that it looks for EmmaEmma-left wing which obviously does not exist. It doesn't do this if you replace the command with a straight line, apparently.

You can get the example to work by temporarily resetting the pic prefix to the value it has outside the pic and then passing the name of the pic through as an option. Clearly this is extremely clumsy and definitely shouldn't be needed. So either this is a bug or something is staring at me and I'm just not seeing it. (This is, after all, basically verbatim from the manual. So it should work!)

\documentclass[tikz,border=3mm]{standalone}
\tikzset{
seagull/.pic={
% Code for a "seagull". Do you see it?...
\coordinate (-left wing) at (-3mm,0);
\coordinate (-right wing) at (3mm,0);
\draw [name prefix ..] (#1-left wing) to [bend left] (0,0) (#1-head) to [bend left] (#1-right wing);
}
}
\begin{document}
\begin{tikzpicture}%\small\sffamily
\pic (Emma) at (0,0) {seagull=Emma};
\pic (Alexandra) at (0,1) {seagull=Alexandra};
\draw  (Emma-left wing) -- (Alexandra-right wing);
\end{tikzpicture}
\end{document}


-
your workaround solve this particular example. But in case, if you like to positioning seagull "Alexandra" relative to seagull "Emma", for example wit help of positioning library: \pic[above=1cm of Emma] (Alexandra) {seagull=Alexandra}; than the error -- no shape named Emma is known -- arise. Since i like to draw set of symbols drawn by pic and each symbol displaced from previous one for distance set for tikzpicture, I need more general workaround about naming of pic (small pictures). I must confess, that after many careful reading of pic description it is still very mysterious to me. –  Zarko Aug 2 '14 at 0:32
@Zarko You cannot say above=1cm of Emma. You can only reference nodes/coordinates inside the pic - not the pic itself. So you wouldn't be able to say that regardless. However, you are quite right that my workaround is extremely unsatisfactory. Just not for that reason. (That problem is just a fact about pics. If you need to be able to reference the whole thing, then you need a node rather than a pic. As I understand the documentation, in any case.) –  cfr Aug 2 '14 at 0:34
I see now. I expected, that the \pic pictures behave similarly as nodes. To this conclusions leads me example "different ways of placing pi" on page 253. In this example I replace absolute coordinate with relative respect to some node and it works. So I expect, that tested example actually show, how to give names to pic (not to elements inside pic) for use in "outside" of pic. Now I'm confused, if I correctly understand you, pic cannot be named on the same way as nodes. If it is so, than for me the example for naming of pic is misleading. –  Zarko Aug 2 '14 at 1:11
cfr: Now I fill quit embraced ... I find solution which gives essdd for one my other question (tikz, conditional setting of shape parameters, tex.stackexchange.com/questions/183036/…). Now I need to rethink my question. –  Zarko Aug 2 '14 at 1:32
@Zarko See the explanation on page 255 The effect of this is, for once, quite different from what happens for nodes: All that happens is that name prefix is set to hnamei at the beginning of the pic. You can say Emma-left wing but you can't say Emma... (Unless I'm extremely confused which I am but I think I get this particular bit.) –  cfr Aug 2 '14 at 2:08

This is indeed a bug, but for a different reason, I think this is happening at the same place when the parsing is done in \tikz@subpicture@handle@ but still I didn't understand perfectly how it goes wrong.

When TikZ starts parsing the last \draw command in the pic code and encounters node names, the name prefix is already set. But the object it is parsing is a node (coordinates are also nodes) so it starts thinking hey, I gotta add a prefix to this reference. Hence another node name prefix is triggered and it looks for that shape. The easiest fix as far as I can see is to refer to explicit coordinates such that node name parsing is avoided, example;

\documentclass[tikz]{standalone}

\tikzset{
seagull/.pic={
% Code for a "seagull". Do you see it?...
\coordinate (-left wing) at (-3mm,0);
\coordinate (-right wing) at (3mm,0);
\draw (-left wing.center) to [bend left] (0,0) (-head.center) to [bend left] (-right wing.center);
}
}

\begin{document}
\begin{tikzpicture}
\pic (Emma) {seagull};
\pic (Alexandra) at (0,1) {seagull};
\draw (Emma-left wing) -- (Alexandra-right wing);
\end{tikzpicture}
\end{document}


This compiles and gives the same result with cfr's picture. Strange indeed. But I think it's not that straightforward to remedy. It might be the case that node name parsing goes awry too, but I didn't check it.

I tried to read the name prefix and see if it matches the node name and if so skip it but didn't succeed. I think this one is for Till Tantau to fix.

-
I don't see that this identifies a 'different reason' from my answer. My answer did not identify any reason whatsoever. It just threw up its hands in horror and expressed confused dismay... (I also found this bit of the tikz code but couldn't understand it well enough to get anywhere with it.) Your workaround is much more straightforward than mine since you clearly have more idea what is going wrong... –  cfr Aug 3 '14 at 1:08
@cfr I meant it is not immediately related to to paths per se. But maybe I was too concise –  percusse Aug 4 '14 at 4:44
No. I probably wasn't very clear. I only meant that to to path triggered something which looked like a bug. I should have said that I didn't think the bug had to do with that as such - only that was what triggered the bug in this particular case. –  cfr Aug 4 '14 at 15:13