Open dpthurst opened 3 years ago
That's a different incarnation of a problem I know very well (see also #369 and #874). Unfortunately, there is no fix yet because it is rooted deeply in the internals of the mathematical engine. Luckily @marmotghost contributed a momentary relief for these situations. In recent versions of PGF you can include the fpu
library and use
\draw[/pgf/fpu/install only=reciprocal,decorate,...
to circumvent the problem. I don't know whether that is available in Debian yet. What version of PGF do you have? (\pgfversion
)
Thanks for the response! That gives me something to look for. That did work for me (with the 'experimental' warning message). \pgfversion gives 3.1.7a.
(But I also have coauthors, so will probably need to work around by tweaking the figure anyway.)
--Dylan
On Fri, Dec 11, 2020 at 11:10:57AM -0800, Henri Menke wrote:
That's a different incarnation of a problem I know very well (see also #369 and
874). Unfortunately, there is no fix yet because it is rooted deeply in the
internal of the mathematical engine. Luckily @marmotghost contributed a momentary relief for these situations. In recent version of PGF you can do include the fpu library and use
\draw[/pgf/fpu/install only=reciprocal,decorate,...
to circumvent the problem. I don't know whether that is available in Debian yet. What version of PGF do you have? (\pgfversion)
??? You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.*
@dpthurst Your co-authors can temporarily work with the install fpu reciprocal
key from https://tex.stackexchange.com/a/529159 until they have version 3.1.7 (or 3.1.6, I am not sure). But I do agree with @hmenke that eventually the problem should be fixed once and for all, switching on the fpu reciprocal is (by far) not a complete solution. Some time ago I had a quick look into this and believed to have identified \pgf@decorate@recursive@subdividecurve@left
and \pgf@decorate@recursive@subdividecurve@right
from pgfmoduledecorations.code.tex
as parts of the reasons, at least I was able to "trick" the decorations based on the way these routines work.
\documentclass[tikz,border=3mm]{standalone}
\usetikzlibrary{decorations.markings,fpu}
\tikzset{my mark/.style={postaction={decorate,decoration={markings,
mark=at position 0.5 with {\arrow{>}}}}}}
\begin{document}
\begin{tikzpicture}
\draw[my mark] (0,0) .. controls (0,1) and (1,1) .. (1,0);
\begin{scope}[xshift=2cm]
% does not work without /pgf/fpu/install only=reciprocal
\draw[/pgf/fpu/install only=reciprocal,my mark] (0,0) .. controls (1,1) and (0,1) .. (1,0);
\end{scope}
\begin{scope}[xshift=4cm]
% claims to work with /pgf/fpu/install only=reciprocal but gives complete nonsense
\draw[/pgf/fpu/install only=reciprocal,my mark] (0,0) .. controls (0,1) and (0,1) .. (0,0);
\end{scope}
\end{tikzpicture}
\end{document}
Whether or not this is helpful, I do not know, I wouldn't mind if this gets deleted because it does not really lead anywhere.
When decorating a path with both the 'snake' modification and marking it with an error, I get a 'dimension too large' error. This seems to be sensitive to the exact dimensions, so I suspect it is a near division-by-zero bug. Below is the smallest I could get this error.
This is on Debian unstable, texlive-pictures version 2020.20201203-2.
Minimal working example (MWE)