0

Again a problem with tikz-uml causing the Extra \or. \end{umlcall} error. However, the solutions from before (here and here) didn't help.

It seems that this is a recent change, since I had a project a year ago (using tex version 2021) that worked without problems, although it now started acting up there too.

The example is taken from the tikz-uml documentation section 5.3.1 "Basic / recursive calls".

Here is a link to my overleaf project: https://www.overleaf.com/read/tbwmdypsgnmg

The error occurs on

  • overleaf with tex version 2021, but can be fixed by adding \usepackage[english]{babel}.
  • the fix does not work for version 2022.
  • I also use Mactex 2023 locally, and have the same issue there too.
  • Also, uploads to Arxiv (which supposedly uses tex-live 2023) yield the error.

Any helpful comments welcome, since I'd like to continue using tikz-uml sequence diagrams.

\begin{tikzpicture} \begin{umlseqdiag} \umlobject [class=A] {a} \umlobject [class=B] {b} \umlobject [class=C] {c} \begin{umlcall}{a}{b} \begin{umlcall}{b}{c} \end{umlcall} \end{umlcall} \end{umlseqdiag} \end{tikzpicture} 

enter image description here

4
  • 1
    Please don't post screenshots of code. Copy and paste it, so that we can copy and paste it. Commented Jul 10, 2023 at 22:08
  • The code is there, including the link to the Overleaf example. I posted the screenshot to highlight which error was raised and where. Commented Jul 11, 2023 at 7:04
  • Hey did you manage to fix your code? I'm stuck just as you are/was. @stklik Commented Sep 30, 2023 at 12:31
  • Run today in the same issue. @JoséJoaquim: Can you fix it? Would be nice to give us a note! Commented May 28, 2024 at 9:04

3 Answers 3

1

Disclaimer: I have no idea how LaTeX works internally, what's the problem with string comparison really and what's the proper solution for it. I can only hope that one day Nicolas himself will come and make a proper fix.

That said, I've also stumbled upon this when some document could be built fine locally, but couldn't be in a CI environment that just used newer LaTeX. https://tex.stackexchange.com/a/721236 helped to fix the build, but as noticed in comments there it has problems with self-calls. So after some pounding on this and trying various approaches I've managed to cook up something that works for me. I don't know why, but it builds and has correct self-calls for my case. Maybe it'll help you as well.

Basically, it's a reuse of https://tex.stackexchange.com/a/391741 for tikz-uml.sty and the patch looks like this:

--- a/tikz-uml.sty +++ b/tikz-uml.sty @@ -136,6 +136,16 @@ fill assembly connector/.get=\tikzumlAssemblyConnectorDefaultFillColor% }% % +% node comparison +% +\newcommand{\ifstringequal}[4]{% + \ifnum\pdfstrcmp{#1}{#2}=0 + #3% + \else + #4% + \fi +} +% % utility : change default colors \newcommand{\tikzumlset}[1]{% \pgfkeys{/tikzuml/.cd,#1}% @@ -879,7 +889,7 @@ % straight line \ifthenelse{\equal{\tikzumlRelationGeometry}{--}}% {% - \ifthenelse{\equal{\tikzumlSrcClassNodeName}{\tikzumlDestClassNodeName}}{% + \ifstringequal{\tikzumlSrcClassNodeName}{\tikzumlDestClassNodeName}{% \def\arcNum{1}% \def\arcNumT{1}% % @@ -896,7 +906,7 @@ \xdef\tikzumlFirstArc{node[midway, inner sep=0, name=\tikzumlRelationName-1, anchor=center] {}}% \xdef\tikzumlMidOneArc{node[midway, inner sep=0, name=\tikzumlRelationName-3, anchor=center] {}}% % - \ifthenelse{\equal{\tikzumlRelationRecursiveDirectionStart}{\tikzumlRelationRecursiveDirectionEnd}}{% + \ifstringequal{\tikzumlRelationRecursiveDirectionStart}{\tikzumlRelationRecursiveDirectionEnd}{% \def\numArcs{3}% \xdef\tikzumlLastArc{node[midway, inner sep=0, name=\tikzumlRelationName-5, anchor=center] {}}% % @@ -1365,7 +1375,7 @@ \fi% \fi% % - \ifthenelse{\equal{\tikzumlRelationRecursiveDirectionStart}{\tikzumlRelationRecursiveDirectionEnd}}{% + \ifstringequal{\tikzumlRelationRecursiveDirectionStart}{\tikzumlRelationRecursiveDirectionEnd}{% \xdef\tikzumlPath{(\tikzumlSrcClassNodeName.\tikzumlRelationStartAngle) -- \tikzumlFirstArc (\tikzumlRelationName-2.center) -- \tikzumlMidOneArc (\tikzumlRelationName-4.center) -- \tikzumlLastArc (\tikzumlDestClassNodeName.\tikzumlRelationEndAngle) }% \ifnum\thetikzumlStateLevel>0% \def\tikzumlStateFitTmp{\csname tikzumlStateFit\tikzumlState@parent @@\tikzumlState@fitname\endcsname}% @@ -4227,7 +4237,7 @@ \expandafter\xdef\csname tikzumlLastChild@\tikzumlCallStartNodeName \endcsname{st-\tikzumlCall@nodeName}% % % top node of activity period of call receiver - \ifthenelse{\equal{\tikzumlCallStartNodeName}{\tikzumlCallEndNodeName}}{% + \ifstringequal{\tikzumlCallStartNodeName}{\tikzumlCallEndNodeName}{% \draw (st-\tikzumlCall@nodeName)+(0,-0.75*\tikzumlCallPadding ex) node[coordinate, name=tikzumlTmpNode] {};% \node[tikzuml activity style] (et-\tikzumlCall@nodeName) at (\tikzumlCallStartNodeName |- tikzumlTmpNode) {};% }{% @@ -4248,7 +4258,7 @@ \ifnum\tikzumlCall@lastchildNum=\thetikzumlCallNum% % % this test occurs a bug with latex package preview - \ifthenelse{\equal{\tikzumlCallStartNodeName}{\tikzumlCallEndNodeName}}{% + \ifstringequal{\tikzumlCallStartNodeName}{\tikzumlCallEndNodeName}{% \draw (\tikzumlCallBottomSrc)+(0,-\tikzumlCallPadding ex) node[coordinate, name=tikzumlTmpNode] {};% \node[tikzuml activity style] (eb-\tikzumlCall@nodeName) at (\tikzumlCallEndNodeName |- tikzumlTmpNode) {};% \draw (eb-\tikzumlCall@nodeName)+(0,-0.75*\tikzumlCallPadding ex) node[coordinate, name=tikzumlTmpNode] {};% @@ -4280,7 +4290,7 @@ \addtocounter{tikzumlCallEndFragmentNum}{-1}% \fi% % - \ifthenelse{\equal{\tikzumlCallStartNodeName}{\tikzumlCallEndNodeName}}{% + \ifstringequal{\tikzumlCallStartNodeName}{\tikzumlCallEndNodeName}{% \draw (\tikzumlCallBottomSrc)+(0,-\tikzumlcallheight ex) node[coordinate, name=tikzumlTmpNode] {};% \node[tikzuml activity style] (eb-\tikzumlCall@nodeName) at (\tikzumlCallEndNodeName |- tikzumlTmpNode) {};% \draw (eb-\tikzumlCall@nodeName)+(0,-0.75*\tikzumlCallPadding ex) node[coordinate, name=tikzumlTmpNode] {};% @@ -4297,7 +4307,7 @@ % % draw activity periods \begin{pgfonlayer}{activity}% - \ifthenelse{\equal{\tikzumlCallStartNodeName}{\tikzumlCallEndNodeName}}{% + \ifstringequal{\tikzumlCallStartNodeName}{\tikzumlCallEndNodeName}{% % draw root activity period only \ifnum\thetikzumlCallLevel=0% \draw[draw=\tikzumldrawcall, fill=\tikzumlfillcall] (st-\[email protected] west) rectangle (sb-\[email protected] east);% @@ -4332,7 +4342,7 @@ % % draw call arrows \begin{pgfonlayer}{connections}% - \ifthenelse{\equal{\tikzumlCallStartNodeName}{\tikzumlCallEndNodeName}}{% + \ifstringequal{\tikzumlCallStartNodeName}{\tikzumlCallEndNodeName}{% \draw[\tikzumlcallstyle, \tikzumldrawcall] (st-\[email protected]) -- ++(2.5*\tikzumlCallPadding ex,0) % -- ++(0,-0.75*\tikzumlCallPadding ex) % node[font=\tikzumlDefaultFont, text=\tikzumltextcall, midway, right, name=\tikzumlCall@nodeName-op] {\tikzumlCallOp} % 
1
  • Please choose a new name for the patched package. Otherwise we might see questions with no indication that the user loads a modified version and this will a nightmare to debug. Commented Nov 21, 2024 at 19:05
1

@roman-khimov

Thank you so much for providing the solution to the \umlcall issue in the tikz-uml package. Your answer was incredibly helpful! 🙏

I wanted to let you know that I’ve created a GitHub repository to host the patch and make it easier for others to apply it. The repository also includes a Makefile and scripts for automating the patching and installation process.

You can find the repository here:

https://github.com/Haixing-Hu/patched-tikz-uml

I hope this helps others who encounter the same issue. Thanks again for your contribution!

1
  • Please choose a new name for the patched package. Otherwise we might see questions with no indication that the user loads a modified version and this will a nightmare to debug. Commented Nov 21, 2024 at 19:04
0

I applied the patch provided in @Roman Khimov's answer against the 2016 version (v1.0) and I confirm that nested calls work.

Automatic patching with git apply says that the file is corrupt, so it seems it needs some maintenance.

But it compiled flawlessly after I manually patched it.

For those interested, you may find the patched version here.

1
  • 1
    Please choose a new name for the patched package. Otherwise we might see questions with no indication that the user actually loads a modified version and this will a nightmare to debug. Commented Nov 21, 2024 at 19:04

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.