Bug 64939 - PDF print jobs created by evince are rendered very slow on PS printers
Summary: PDF print jobs created by evince are rendered very slow on PS printers
Alias: None
Product: cairo
Classification: Unclassified
Component: pdf backend (show other bugs)
Version: 1.12.14
Hardware: Other All
: medium normal
Assignee: Adrian Johnson
QA Contact: cairo-bugs mailing list
Depends on:
Reported: 2013-05-24 06:33 UTC by Alex Prokofiev
Modified: 2013-08-21 13:52 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Sample PDF with shadow (31.17 KB, application/pdf)
2013-05-24 06:33 UTC, Alex Prokofiev
PDF file sent by evince to print server (213.23 KB, application/ofx)
2013-05-24 06:37 UTC, Alex Prokofiev
PS from pdftocairo -ps (456.94 KB, text/plain)
2013-05-24 11:52 UTC, Alex Prokofiev
Same PS from pdftocairo, but shaded areas removed (58.49 KB, text/plain)
2013-05-24 11:53 UTC, Alex Prokofiev
LaTeX file used to create original PDF (159 bytes, text/plain)
2013-05-28 09:03 UTC, Alex Prokofiev

Description Alex Prokofiev 2013-05-24 06:33:50 UTC
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.
Comment 1 Alex Prokofiev 2013-05-24 06:37:41 UTC
Created attachment 79736 [details]
PDF file sent by evince to print server
Comment 2 Alex Prokofiev 2013-05-24 06:39:12 UTC
Forgot to mention: printing "source" file, not transformed by evince,
Comment 3 James Cloos 2013-05-24 11:11:05 UTC
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.
Comment 4 Alex Prokofiev 2013-05-24 11:52:26 UTC
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.
Comment 5 Alex Prokofiev 2013-05-24 11:52:59 UTC
Created attachment 79762 [details]
PS from pdftocairo -ps
Comment 6 Alex Prokofiev 2013-05-24 11:53:45 UTC
Created attachment 79763 [details]
Same PS from pdftocairo, but shaded areas removed
Comment 7 James Cloos 2013-05-24 15:47:11 UTC

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.)
Comment 8 Alex Prokofiev 2013-05-28 09:03:18 UTC
Created attachment 79888 [details]
LaTeX file used to create original PDF

LaTeX file should be compiled with pdflatex

My TeX distribution: TeX Live 2011
Comment 9 James Cloos 2013-05-28 15:15:26 UTC
> LaTeX file used to create original PDF

Oh. That simple?


leads to:







  \setbeamertemplate{title page}[default][colsep=-4bp,rounded=true,shadow=\beamer@themerounded@shadow]
  \setbeamertemplate{part page}[default][colsep=-4bp,rounded=true,shadow=\beamer@themerounded@shadow]





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.
Comment 10 Alex Prokofiev 2013-06-03 05:14:03 UTC

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.