Open kberry opened 3 years ago
Hi Henri - well, 824 is about transparency, so that seems different (though with the same ultimate result of crashing the RIP).
984 is about save/restore. I guess that could be the issue with 3d too, but it didn't seem like it. Our printer person said specifically the 3d crash here is about "too many vectors". Thus my uninformed guess is that tikz is rendering the 3d at some amazingly high resolution.
By the way, in this (3d) case I haven't had trouble rendering on-screen with my old and favorite xpdf. I haven't tried other viewers.
Thanks for checking into it. --best, karl.
Just for posterity, Barbara asked a prior colleague at the AMS about this, and he mentioned: 1) inkscape --query-all, which prints a list of svg objects including paths. He said the marmot graphic has almost 500 paths. (Which doesn't seem very excessive to me, but I guess it was.)
2) https://github.com/scour-project/scour, a program to clean/optimize vector graphics.
I haven't tried either of them, but just to mention ... --best, karl.
Just out of curiosity, what TeX engine was used? And what version of pgf
?
It used to be the case that if you went the LaTeX → DVI → PostScript route that shadings where approximated with many paths slightly varying in shade.
Pull request https://github.com/pgf-tikz/pgf/pull/907 switched to using PostScript Level 3 shadings.
For comparison with above comment:
Using this TeX file compiled with pdflatex
:
\documentclass{article}
\pagestyle{empty}
\usepackage{tikzlings}
\begin{document}
\tikz{\marmot[3D]}
\end{document}
inkscape --query-all
gives me a very modest 14 paths.
If you were using latex
and an old version of pgf
you'd get a much larger number of paths.
Hi David - thanks for that follow-up.
Sorry for failing to mention the engine. It was indeed pdflatex (pdfTeX 3.141592653-2.6-1.40.22 (TeX Live 2021)) and the tikz that was (still is) current in TL. \listfiles reports:
tikzlings.sty 2021/03/17 version v0.5
tikz.sty 2020/12/27 v3.1.8b (3.1.8b)
pgf.sty 2020/12/27 v3.1.8b (3.1.8b)
I get 40 paths from inkscape --query-all | grep \^path | wc, and another 97 "g" lines (whatever they are), which one would hope would not overflow anything. I was expecting thousands.
Although the printer said the problem was specific to that image, maybe it was actually about the sum total of paths on the entire path, which had quite a few tikzlings. It still doesn't seem like anything that should overflow a RIP nowadays, but there it is.
Anyway, I guess that --query-all shows that there is nothing to do on the tikz side here, so I further guess this can be closed ... --thanks, karl.
The 3d marmot included in the tikzlings package,
caused an error at TUGboat's commercial printer because of "too many vectors". (I posted the msg from them at https://tex.stackexchange.com/questions/615662, but it doesn't say anything much beyond "you overflowed our RIP".)
The package uses tikz for this.
So ... is there a way to control the tikz 3d rendering level (whatever that might mean ... how many rays get traced, or whatever) in some way? And maybe it could be decreased by default with no visible effect? I rather doubt that such a terrifically high level so as to overflow a commercial RIP is necessary.
Thanks for any clues.