# tikzscale and \tikzsetnextfilename do not work together

\tikzsetnextfilename does not work with tikzscale package. In the MWE, included file is A.tikz which should produce A.pdf. MWE works if tikzscale is not used.

MWE:

\documentclass{report}
\usepackage{tikz,tikzscale}
\usetikzlibrary{external}
\tikzexternalize
%
\begin{filecontents}{A.tikz}
\begin{tikzpicture}
\draw (0,0) rectangle (2,2);
\end{tikzpicture}
\end{filecontents}
%
\begin{document}
\newcommand{\figFilename}{}
\renewcommand{\figFilename}{A}
\tikzsetnextfilename{\figFilename}
%\input{\figFilename.tikz}
\includegraphics[width=\linewidth]{\figFilename.tikz}
\end{document}

-
@cyberSingularity main-figure0.pdf is created instead of A.pdf. I am using tex-live 2012 updated yesterday. – devendra Dec 19 '12 at 0:04
Sorry, you are right. I hadn't checked carefully enough. It seems to be that calling \tikzexternalgetnextfilename (as the tikzscale package does) actually unsets the next filename. Perhaps a bug in tikz. Adding the following to the preamble fixes it: \let\oldtikzexternalgetnextfilename\tikzexternalgetnextfilename \renewcommand{\tikzexternalgetnextfilename}[1]{\oldtikzexternalgetnextfilename{#‌​1}\expandafter\tikzsetnextfilename\expandafter{#1}} – cyberSingularity Dec 19 '12 at 0:37
Actually, this seems to be the intended behaviour of \tikzexternalgetnextfilename. But probably tikzscale isn't aware of it, especially as I haven't found any documentation of the macro in tikz. So one probably shouldn't patch that macro, but the tikzscale package should restore the filename after querying it? Perhaps contact the package author? – cyberSingularity Dec 19 '12 at 0:54
@cyberSingularity Will do that. – devendra Dec 19 '12 at 1:33
@cyberSingularity, thank you both for your findings and suggestions. Unfortunately, at the moment either the file name setting or a test in the test-suite is broken (when the suggested workaround above is implemented), I cannot get both working at the same time. So instead adding a regression, I want to wait for Christian's answer, whom I contacted. My suggestion is, that he adds a macro \pgfexternalreadnextdpth, which encapsulates the behaviour so that tikzscale does not have to call the problematic \tikzexternalgetnextfilename at all. – Patrick Häcker Dec 19 '12 at 22:24

With Christian's fix of "get next filename", which is already built and can be downloaded, the mentioned problem seems to be fixed, too. Thanks for the report and please post if the problem still occurs to you.

-
Thank you for letting me know. I use texlive-2012 on ubuntu. When is this new build likely to come to texlive? I am not comfortable with installing it myself. A quick search on google tells me that I should unzip the file in the local texmk directory. But what will happen to the old version of PGF? – devendra Dec 30 '12 at 18:35
If the Ubuntu people didn't change the Debian package, you can create a directory named "texmf" in your home directory and unzip the linked tds-file into that directory. From then on, the new TikZ version is automatically used, while the old version stays completely untouched. You can delete (or temporarily rename) the texmf directory in your home directory at any time so that the distribution's version is used again. It really is that simple (much simpler than I once thought). – Patrick Häcker Dec 30 '12 at 21:30
The fix works nicely. Thank you. Could you also take a look at these questions. I might have to remove them as they are considered as bug reports. tex.stackexchange.com/questions/89027/… and tex.stackexchange.com/questions/89053/… – devendra Jan 3 '13 at 12:09
@PatrickHäcker I used the new PGF release where the bug is fixed. However, the figures keep compiling in each run of LaTeX. seems that the PDFs generated by externalization are being recompiled. What is the way to fix this? – M.Reza Jun 30 '14 at 5:16