To resolve the problem I described here, I need to use pgfplots version 1.13, which required that I updated to TeX Live 2015. Doing so lead to a problem with the command \heightof as can be seen by running the MWE

\node[text height=\heightof{$\pi/2$}] {Text};

which leads to

! Undefined control sequence.
\tikz@text@height ->\heightof 
                              {$\pi /2$}
l.5 \node[text height=\heightof{$\pi/2$}] {Text};

So I need TeX Live 2015 for some of my figures, but this breaks other figures, which work fine with TeX Live 2014. I have already reported this problem on SourceForge - originally believing it to be a pgfplots problem - where Christian Feuersänger pointed out that it's actually a problem with pgf.

As of today, the bug report is still open, which - I want to make this very clear - I am not complaining about. Instead, I want to ask one practical and one less practical question. The practical one:

How can I get around both problems until the bug is fixed? I'm happy with a kludgy workaround, but I would like to avoid having to process my figures in two groups according to whether they need TeX Live 2015 or 2014. The reason is twofold. First, my document is rather large (100s of .tex files). Second, it is processed with several Makefiles.

My less practical question arose out of my curiosity and experience with developing and testing complex software: Do new versions of pgf, TikZ, and pgfplots undergo automated regression testing before they are released (and incorporated into TeX Live, for example)? It appears not, but I find this odd given the background of Till Tantau and Christian Feuersänger in Computer Science and Numerical Simulation, so I must assume I am wrong and that they do undergo automated regression testing. Am I missing something?

Let me state again that I am not complaining about pgf and pgfplots. I am very grateful for them and enjoy the high-quality figures they allow me to produce.

  • 2
    \heightof is a macro from calc package. But it won't work even with \usepackage{calc} (at least not this way)
    – user31729
    Jan 26, 2016 at 20:18
  • Note that while it's convenient to talk about 'TeX Live <year>', the majority of the code is not written by the TL team nor updated only once per year. That is (broadly) true for the engine binaries (so pdftex, etc.) but not for individual packages. Here, the rest of TL has nothing to do with the issue, which is as noted due to the fact calc is needed to define \heightof. Presumably internal changes in pgf mean this is no longer loaded (and indeed adding it manually doesn't solve the issue, so there must be other changes). However, that's not the fault of the TL team or other ...
    – Joseph Wright
    Jan 26, 2016 at 20:21
  • 1
    ... package authors. Each package author is free to define their own release schedule, testing approach and so on. (For the core LaTeX team work there is a test suite and we do pay close attention to the TL cycle. However, that's atypical. You can't even assume that the engines get regression tested, as it's not unknown for the LaTeX test suite to find all sorts of interesting thing!)
    – Joseph Wright
    Jan 26, 2016 at 20:22
  • @Joseph Wright: I know that the TL team does not develop the majority of the code and that it is updated more than once a year. I am not looking to blame anyone. I am simply wondering whether pgf, TikZ, and pgfplots, and, by extension, TL, undergo automated regression testing before they are released. If they are not, shouldn't they? Jan 27, 2016 at 19:35
  • @Christian Hupfer: I did not need the calc package with TeXLive 2014. Jan 27, 2016 at 19:43

2 Answers 2


guessing the intended meaning, you can do this:


\node[text height=\zzz] {Text};
  • All true but this did work with the last TL2014 version of pgf, so presumably a change between pgf 3.0.0 and 3.0.1a involved dropping support for \heightof inside expressions.
    – Joseph Wright
    Jan 26, 2016 at 20:24
  • 2
    @JosephWright yes but the question was how to work around the issue not how to debug pgf internals:-) making the above change makes the document work... Jan 26, 2016 at 20:29
  • The reason why I use \heightof is that I want to align tick labels on the same baseline. (For example, \pi, \pi/2, etc.) Is the solution you suggest formally identical to the MWE or are there any subtleties that could lead to later problems? I'm asking because your workaround would mean that I convert all my figures using \heightof. Jan 27, 2016 at 19:53

There has been a significant change in the definition of the internal macro \pgfmathparse@. The older version includes a set of compatibility lines for use with calc which have (presumably deliberately) been removed. Adding those back in but otherwise keeping the new definition gives

    % Stuff for calc compatiability.
    % No (math) units yet. 
    % Expand expression so any reamining CSs are registers
    % or box dimensions (i.e. |\wd|, |\ht|, |\dp|).
        % this here is the _real_ parser. it is invoked by
        % \pgfmathparse@trynumber@loop if that says "this is no number"

where the set added are those at the start.

  • So what you are suggesting is that I put this into a file and \input it while I'm using TL 2015? (This worked for the MWE.) Jan 27, 2016 at 19:47
  • 1
    @user1362373 I'm suggesting you put it in your source files marked up as a 'temporary patch' until it's addressed by the pgf maintainers. If you want to be cautious you could use \@ifpackagelater to only patch the latest release.
    – Joseph Wright
    Jan 27, 2016 at 19:48
  • Instead of redefining \pgfmathparse@ I would recommend using \pretocmd{\pgfmathparse@}{\let....}{}{}, so that other further changes of \pgfmathparse@ are applied. (However, I could not test it, as I don't have the current texlive installed)
    – Scz
    Aug 17, 2016 at 14:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .