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 version: Ubuntu 12.04
cups: 1.5.3 (using pdftopdf and pdftops filters)
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,
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
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?
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”
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.
pdftocairo -level2 works on both printers with acceptable speed.
Sorry for delay - I was unable to check this for last week.