Created attachment 79735 [details] Sample PDF with shadow When printing some PDF files from evince, PS printers are very slow to produce output (PDF gets converted to PS with pdftops and then send to printers). I've tried 2 printers: - HP Laserjet P3005 prints page after 2-5 minutes of processing, - Xerox Phaser 4600 just shows "Formatting ..." message and don't print at all in reasonable times. Client computer (with evince) information: OS: Gentoo evince: 2.32.0 cairo: 1.12.14 poppler: 0.22.2 Print server: OS version: Ubuntu 12.04 cups: 1.5.3 (using pdftopdf and pdftops filters) poppler-utils 0.20.5-1ubuntu3 cups-filters 1.0.18-0ubuntu0.1 libcairo2 1.12.14-0ubuntu1 Attached is sample PDF presentation created by latex with beamer package. The problem is title shadow - removing it in PS file makes both printers print fast. This bug is somewhat different from other "slow print" bugs, as all ghostscript-based utilities process this file fast, and viewing on screen is also fast. Only printers fail to print it.
Created attachment 79736 [details] PDF file sent by evince to print server
Forgot to mention: printing "source" file, not transformed by evince, works.
That pdf has a function with hundreds of sub-functions. I bet that is where things slow down. The ps2 and ps3 translations made by pdftops(1) generate a nested ifelse tree. That might overwhelm the resources of embedded PS interpreters. The output from pdftocairo -ps uses a different translation of the stitching functions with a /Bounds array just like in the pdf. That might work better on printers.
Tried with pdftocairo -ps, job didn't print: gave "insufficient memory" after 6 minutes or so. OTOH, same file with shaded areas removed started to print almost instantly.
Created attachment 79762 [details] PS from pdftocairo -ps
Created attachment 79763 [details] Same PS from pdftocairo, but shaded areas removed
Appologies. I was grabbed the 2nd attachemnt rather than the first (while reading the email feed). Compared to what poppler/splash (via pdftops) with the original pdf, the poppler/cairo output (via evince or pdftocairo) is wierd. I can’t tell whether this is a poppler or cairo issue, though. (IMO Evince’s refusal to pass pdf and ps files through to the print system unmolested is a bug in Evince, and would avoid this bug. (Is the ΤεΧ src available? I’m curious where the value (8388608+94)/1048576 – as opposed to 8.0 – in the shading originated.)
Created attachment 79888 [details] LaTeX file used to create original PDF LaTeX file should be compiled with pdflatex My TeX distribution: TeX Live 2011
> LaTeX file used to create original PDF Oh. That simple? \usetheme{Madrid} leads to: /usr/share/texmf-site/tex/latex/beamer/base/themes/theme/beamerthemeMadrid.sty with: \useinnertheme[shadow]{rounded} to: /usr/share/texmf-site/tex/latex/beamer/base/themes/inner/beamerinnerthemerounded.sty with: \setbeamertemplate{blocks}[rounded][shadow=\beamer@themerounded@shadow] \setbeamertemplate{title page}[default][colsep=-4bp,rounded=true,shadow=\beamer@themerounded@shadow] \setbeamertemplate{part page}[default][colsep=-4bp,rounded=true,shadow=\beamer@themerounded@shadow] to: /usr/share/texmf-site/tex/latex/beamer/base/beamerbaseboxes.sty with: \ifbmb@shadow% \setbox\bmb@boxshadow=\hbox{\pgfuseshading{bmb@shadow}}% \setbox\bmb@boxshadowball=\hbox{\pgfuseshading{bmb@shadowball}}% \setbox\bmb@boxshadowballlarge=\hbox{\pgfuseshading{bmb@shadowballlarge}}% \fi% so the shadowing comes from pgf and thense from tikz. And the slightly-larger-than-an-integer values come from shifting the shadow a fraction of an ex right and down from the object which “casts” the shadow. Interestingly, when nor writing to pdf, tikz uses a set of lines of decreasing ink density to simulate the shadow, rather than using a shading as it does with pdf. For pdf, tikz outputs linear shadings for the bottom and the right, and radial shadings for each of the three rounded corners. If you call: pdftocairo -ps -level2 att-79735.pdf att-79735-cr.ps2 you get a LanguageLevel 2 ps file which might work on your printers. By default, cairo’s ps output is level 3, and shadings are output as ps shadings. Your printers might not support them. All of the other pdf→ps conversions, and tikz’s ps output, simulate shadings instead of coding them as shadings. If it does, then those printers probably do not support LanguageLevel 3, notwithstanding whether they claim to. The real bug is that evince fails to send the original file to the print queue. This makes evince a poor choice for printing documents.
Thanks! pdftocairo -level2 works on both printers with acceptable speed. Sorry for delay - I was unable to check this for last week.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.