Andrew Stacey

So, in conclusion, shorten should be applied to the original path only, and avoided when rendering components.

In the above, then the yellow path goes exactly along the centre of the black path (whereas the green is slightly off), and it ends exactly on the boundary of the circle at the intersection point.

\documentclass[tikz,border=3pt]{standalone}
%\url{tex.stackexchange.com/a/720532/86}
\usetikzlibrary{spath3,intersections}

\begin{document}
\begin{tikzpicture}[
    fancy dashed/.style={shorten <=5pt,shorten >=5pt},
  ]
  \coordinate (yy) at (6.8,-0.4);
  \coordinate (ww) at (7.75,0.7625);
  \coordinate (pp) at (0.75,-2.25);
  \coordinate (qq) at (2.5,-2.25);
\coordinate (ctrl) at (9,-1.5);
\foreach \cdt in {yy,ww,pp,qq,ctrl} {
  \fill[cyan!50!black] (\cdt) circle[radius=5pt];
  }
  \path[spath/save=pparrowyy,draw, fancy dashed, line width=2mm, line cap=butt ] (pp) to[out=-30,in=23…

Sorry, 12.5pt since it gets split in twain.

In the above code, then I apply the shortening to the original path (in black), and then also to the green path. As you can see, the green path is not fully centred on the black path. This is why I think it best to apply the original shortening to the original path and then use the correct width when inserting gaps. So to get the best approximation of what you originally had, I would put the shorten keys on the original path, and then use 6.25pt in the gaps.

\documentclass[tikz,border=3pt]{standalone}
%\url{tex.stackexchange.com/a/720532/86}
\usetikzlibrary{spath3,intersections}

\begin{document}
\begin{tikzpicture}[
    fancy dashed/.style={shorten <=5pt,shorten >=5pt},
  ]
  \coordinate (yy) at (6.8,-0.4);
  \coordinate (ww) at (7.75,0.7625);
  \coordinate (pp) at (0.75,-2.25);
  \coordinate (qq) at (2.5,-2.25);
\coordinate (ctrl) at (9,-1.5);
\foreach \cdt in {yy,ww,pp,qq,ctrl} {
  \fill[cyan!50!black] (\cdt) circle[radius=5pt];
  }
  \path[spath/save=pparrowyy,draw, fancy dashed, line width=2mm, line cap=butt ] (pp) to[out=-30,in=23…

It may be (need to read the manual) that the shorten keys are affected by the tips keys which would provide another way to achieve the same end.

So when the fancy dashed style is applied to the whole pparrowyy path after it has been split, then only the second component gets the shortening. This means that the gap is width 1.25pt before the intersection point and 6.25pt after it (1.25pt being half of 2.5pt). So either we specify the full desired width initially or we need to ensure that the shorten keys are applied to all components. One way is to render each component separately, as you did.

(Second bother: I can't just paste an image directly into the chat, I have to save it and upload it ... it's too late in the evening for that right now so you can run the above code for yourself and see that the red line is shortened only on the second component.)

\draw[line width=2mm] (0,0) to[out=0,in=180] (2,0) (2.5,0) to[out=0,in=180] (4,0);
\draw[red,shorten <=5pt, shorten >=5pt] (0,0) to[out=0,in=180] (2,0) (2.5,0) to[out=0,in=180] (4,0);

So, most significantly, by default then if you specify shorten >=5pt, shorten <=5pt on a fragmented path then it applies it to the last component only.

(Bother, I forgot that hitting enter submitted the comment - ah well, you'll get notified of that one and then hopefully see the rest!)

@cfr Okay, there's some interesting stuff going on here. Most of it is TikZ rather than spath3.

@cfr sorry, it's been a very long time since I've used the chat facilities here and I've forgotten much ...

Right, this is where I need to try out some code variations. I have theories as to what is going on and it's to do with the interactions between the shortening stuff, but I need to try it out go be sure.

Oh, that worked!

Just testing if I can now comment

\path [spath/use=pparrowyy,draw,green,fancy dashed]; should work (I can't test on this device).

Not at all! It's a superb answer - really well explained. I'm bookmarking it as my canonical explanation of how to achieve this.

The only comment I have is that at the end it isn't necessary to loop through the components since they're all being drawn with the same style so it can be done with a single \path command. You could give a second example with a different style applied to each component to show the difference.

Fabulous! (And some more characters to get over the limit)

I recommend that you take a look at the lwarp package.

@DavidCarlisle \pi_1-eating contest?

@AlanMunn Hmm, what would a topology-fight look like? Bagels at dawn?

@AlanMunn That's what I'm hoping for. I'm a bit worried it's because I provided an answer to a question with an already accepted answer that is quite detailed and that has had a fair amount of work put into it.

I suppose I should regard it as a sign of how pleasant this place is that it really smarts when I get a down-vote on an answer with no reason given.

@UlrikeFischer I'll go for hobby-l3draw then. Only now that I've looked at the code I can see that it needs a fair bit of re-organising before I submit the next version. sigh

Is hobby4l3draw too confusing??

@UlrikeFischer I wasn't sure if there was a convention yet for l3draw in particular and l3 in general. I'll go for something like what you said.

@UlrikeFischer Err ... not sure if I'm missing something, but when you put \usetikzlibrary{abc} in the preamble then it looks for the file tikzlibraryabc.code.tex

The core algorithm file is in hobby.code.tex.

@UlrikeFischer The TikZ/PGF libraries are called tikzlibraryhobby.code.tex and pgflibraryhobby.code.tex.

I've been sitting on a few bug fixes for this package for a while and want to get them to CTAN, and I may as well add the interface to l3draw as well. At the moment, my file is called l3hobby.sty but I have a recollection that that type of name is reserved for the l3 core stuff so I should rename it.

@UlrikeFischer My hobby package splits into several pieces, there's the underlying implementation of the algorithm which makes no assumptions on how the path will actually be rendered, and then there's interfaces with actual drawing packages. Originally, it was just TikZ but when l3draw came along I realised it would be easy to adapt to that (I think Joseph helped a bit) so I designed that interface as well.

Hey all, especially L3 folks. Can someone remind me of the naming convention for L3 packages? I know I'm not supposed to call a package l3hobby, but if I want to upload the interface for the hobby code with l3draw, what should I call it the relevant style file?

@DavidCarlisle Maybe I need to think a little bit more about the use cases to see if I can always detect whether the intention is local or global. It may be that a top level user is pretty much guaranteed to use it globally, but a programmer might use local and I'm more okay with asking a programmer to stick to the guidelines.

@UlrikeFischer I originally had everything as global to avoid this issue, but then I found myself wanting to work both globally and locally. Trouble with requiring explicit naming is that I don't think I can rely on users to actually obey that.

(I do tend to struggle with TeX's functional approach to programming. I'm much more inclined towards an object oriented approach.)

@UlrikeFischer They don't define it as a macro but as a string. So they might say \DefineMyStructure{weird name} and this would get filtered down through the levels to a prop called \l__secret_code_weird name_prop. I'm trying to hide the implementation in an abstraction layer.

@DavidCarlisle The distinction between local and global is not necessarily clear. If the underlying data structure is global does that mean that all of its data needs to always be global? But what if a user wants to modify a part of it in a group but have the original definition restored after the group? That's local modification of a global variable.

@MarcelKrüger I do provide the local and global functions, but it's the name of the underlying prop that holds the data which I'm pondering. The user provides a string (not a macro) which is used to build the prop variable name but I append a secret prefix as a way of protecting the prop from being directly accessed.

But at design time I don't know if the structure will be used in a local scope or a global one so I don't know whether to make x an l or a g.

@UlrikeFischer @DavidCarlisle Hmm, okay a few more details might help. I'm defining a data structure which is implemented as a prop, but has specific attributes and methods of its own. I don't want to expose the underlying prop to the user as I want them to go through the methods that I've defined. So to disguise the prop, and avoid name clashes, I allow the user to specify a name and then create the object as \x__secret_prefix_<their name>_prop.

Question to the LaTeX3 style gurus. If a variable might be used locally or globally, is there a prefix to indicate that? If I do \tl_gset:N \l__weird_tl {stuff} then the expl3 checker warns me about using a local variable in a global manner. But sometimes that's just gotta be done. Is there a right way to do this, or do I just shrug it off?

@FrankMittelbach Do let me know if there's anything I can do to help.

github.com/latex3/latex3/issues/829

\AddToHook{file/after/pgfmorepages.sty}[firstaid]{%
  \cs_set_nopar:Npn \pgfhookintoshipout {
    \cs_set_eq:NN \pgfpages@originalshipout \tex_shipout:D
    \cs_set_eq:NN \tex_shipout:D \pgfpages@interceptshipout
  }
}

@UlrikeFischer Will do. I'll post this there, but for the record here as well then I get that the hook should be:

Oh, hang on. I have an idea as to what the problem is. You've just copied the pgfpages fix into the pgfmorepages one. They call \pgfhookintoshipout at slightly different times. pgfpages calls it at the end of the package whereas pgfmorepages calls it via an AtBeginDocument hook. So when your firstaid patch gets run then \pgfpages@originalshipout isn't defined and thus \shipout gets set to undefined. So I think that you need to remove the first line from your hook.

This causes an undefined command error in all engines (pdflatex, xelatex, lualatex)