Bug 64939

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.