pgf-tikz
Error: limitcheck; OffendingCommand: save with Acrobat Distiller
\Tree command produces a lot of postscript save restore commands. And this is a problem with ps->pdf conversion using acrodist.exe. GhostScript (or ps2pdf) doesn't seem to have a problem with that. But some publishers requires to use acrodist.exe with their joboptions.
Here is error message:
%%[ Error: limitcheck; OffendingCommand: save ]%%
Stack:
-save-
-save-
-save-
-save-
-save-
-save-
-save-
-save-
-save-
-save-
-save-
-save-
-save-
-save-
-save-
-save-
-save-
-save-
-save-
-save-
-save-
-save-
%%[ Flushing: rest of job (to end-of-file) will be ignored ]%%
%%[ Warning: PostScript error. No PDF file produced. ] %%
limitcheck; OffendingCommand: save as I understand means that it is to many opened save without restore.
MWE:
\documentclass{article}
\usepackage{tikz}
\usepackage{tikz-qtree}
\begin{document}
\Tree [.A [ [.C ] [.D ]] ]
\end{document}
Could it be possible to fix it in the future? same issue here
The first comment is actually mine. Why can't you just provide the resulting PDF instead of the PS-PDF conversion? Otherwise this one might be suitable for the tikz-qtree maintainers.
Since Adobe Distiller is not available for GNU/Linux, there is no possibility for me to reproduce this error, sorry. It looks like you are on your own. Please also note that tikz-qtree (https://ctan.org/pkg/tikz-qtree) is not part of tikz.
However, if it really a stack overflow, as you have suggested, there must be something that creates an excessive number of scopes.
Hm, I just checked the MWE and the resulting Postscript file doesn't really contain a lot of saves.
$ dvilualatex test.tex
$ dvips test.dvi
$ grep -c -w save test.ps
43
Because this is a typesetting workflow based on DVI workflow. That workflow is strongly adapted with lots of postscript specials to prepare a PS file suitable for production with acrodistiler.
In DVI I can find 32
special1 13 'ps:: save '
special1 13 'ps:: restore '
problem is that save are going to the stack that reaches the limit in Acrobat Distiler. Probably restore pops that counter but they are at the end of tree. Ghostscript limits are bigger. And I didn't find how to enlarge distiler limits
Since this package is related to pst-tree I am guessing that the author directly translated PS directives into tikz-qtree and something got lost in between. If this also happens if you create a tree via pst-tree then we can't be of much help.
Also I would really question the typesetting requirements. The idea of the distiller is to get to the PDF. If you provide a flattened PDF this step shouldn't be needed at all and the publisher is just making excuses.
The save-restore stacks in both dvi and ps files are correct. Every save is properly restored. I guess the used stack could be too deep that exceeds the implementation limits of Adobe Distiller, a software I heard about but never used. You can try nesting \special{ps::save} ... \special{ps::restore} to find the limitation.
To see the contents of a dvi, run dviasm test.dvi -o test.dump. See https://ctan.org/pkg/dviasm.
As I understand pgf team has nothing to do with this ticked only author of tikz-qtree can tell is there another way to build PS code with less deep save . .restore stack.
I've had a look at the tikz-qtree source code. It's a very tiny package that doesn't really do much beyond translating this dotted syntax into \pgftree, so this issue has definitely something to do with either PGF or Adobe Distiller. However, since Distiller is a commercial product we cannot reproduce the error and if I understand Wikipedia correctly, Distiller has also been discontinued.
Oh, by the way, since you are a paying customer of Adobe, why don't you send your Postscript file to them and tell them that this crashes Distiller but not Ghostscript? They will be able to tell you whether this is a problem with Distiller or with the Postscript.
There is no good news from Adobe. They suggested just to rewrite PS code to avoid this limitation. here
That leaves the question as to what the limit is. I can't find anything under the suggested keyword "PSLRM". It's also not clear whether there is a limit on the total number of saves or whether every restore pops one off the limit. In the latter case we might be able to work around the problem by some clever reordering of operations in \pgftree, although it's sort of questionable whether that's worth it. After all Ghostscript works just fine.
I'm shore that one save should pop one restore. Because it's a simple example and it run out of the limits. Usually save/restore are used a lot and there is no problem with that.
That leaves the question as to what the limit is. I can't find anything under the suggested keyword "PSLRM". It's also not clear whether there is a limit on the total number of
saves or whether everyrestorepops one off the limit.
I guess "PSLRM" refers to the PostScript Language Reference Manual, 3rd edition (PDF). From its Table B.1 Architectural limits, Appendix B, save has a limit of 15:
QUANTITY LIMIT DESCRIPTION save level 15 Maximum number of active save operations that have not yet been matched by a corresponding restore.
I hardly know anything about PostScript. Above is just a casual search.