pgf-tikz / pgf

A Portable Graphic Format for TeX
https://pgf-tikz.github.io/
1.12k stars 106 forks source link

Reduce number of shading vectors #1054

Open kberry opened 3 years ago

kberry commented 3 years ago

The 3d marmot included in the tikzlings package,

\documentclass{article}
\usepackage{tikzlings}
\begin{document}
\tikz{\marmot[3D]}
\end{document}

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.

hmenke commented 3 years ago

Related? https://github.com/pgf-tikz/pgf/issues/824 https://github.com/pgf-tikz/pgf/issues/984

kberry commented 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.

kberry commented 3 years ago

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.

dcpurton commented 2 years ago

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.

kberry commented 2 years ago

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.