Evince does not print images in some pdf files.

Bug #537970 reported by imachine on 2010-03-12
This bug affects 8 people
Affects Status Importance Assigned to Milestone
cups (Ubuntu)
Till Kamppeter
gtk+3.0 (Ubuntu)
poppler (Ubuntu)

Bug Description

Binary package hint: evince

Evince fails to print the image in .pdf file.

It shows up correctly in preview, acroread prints it properly.

To reproduce:

1) Download this here invoice: http://www.mlink.net.pl/~imachine/faktura_24_2010_12-03-2010.pdf
2) Preview in Evince - company logo is here.
3) Print - company logo is not on paper.

Frustrating, used to work, just stopped at some point, too far back in time now to find out tho :/


ProblemType: Bug
Architecture: amd64
Date: Fri Mar 12 10:58:00 2010
DistroRelease: Ubuntu 10.04
ExecutablePath: /usr/bin/evince
NonfreeKernelModules: nvidia
Package: evince 2.29.91-0ubuntu2
ProcVersionSignature: Ubuntu 2.6.32-16.25-generic
SourcePackage: evince
Uname: Linux 2.6.32-16-generic x86_64

Bug forwarded from Evince: https://bugzilla.gnome.org/show_bug.cgi?id=600181

"Evince version: 2.28.1 on Ubuntu 9.10.

Evince cannot display any pages of the document without significant errors
--the PDF consists entirely of image files containing text, and almost all of
the text is invisible. Sometimes multiple pages of the same document are
displayed where the user would expect only one page (again, the text within the
image is missing). This behavior is inconsistent and I don't know how to
consistently reproduce it.

Xpdf displays the document without errors.

Thank you."

"The PDF file can be downloaded from here:


This is another bug in CairoOutputDev::drawImageMaskPrescaled().

imachine (m-jedrasik) wrote :
madbiologist (me-again) wrote :

The company logo prints fine here with Ubuntu 10.04 alpha 3.

Uname: Linux 2.6.32-16-generic i686
Package Versions: evince 2.29.92-0ubuntu1
                               poppler 0.12.4-0ubuntu1
                               libcairo2 1.8.10-2ubuntu1

Can you try updating and report back here?

Changed in evince (Ubuntu):
status: New → Incomplete
imachine (m-jedrasik) wrote :

Same versions (libpoppler5) the logo just isn't there.

Could it be SPLIX error?

imachine (m-jedrasik) wrote :

splix 2.0.0-2ubuntu3 is what I have

madbiologist (me-again) wrote :

I have the same version of splix as you, although it's probably not being used as I have a Canon printer, not a Samsung printer.

Did you update evince to 2.29.92-0ubuntu1 ?

imachine (m-jedrasik) wrote :

Yes, I have updated my Ubuntu to the latest version, as of the first post I have been running 2.29.92-0ubuntu1

imachine (m-jedrasik) wrote :

I hardly believe it is a splix related issue.

Till Kamppeter (till-kamppeter) wrote :

I have done some updates in the last days, please update your Lucid system and try again, especially the last update on Ghostscript is important.

imachine (m-jedrasik) wrote :

Yes, now I keep getting udev-configure-printer segfaults :) https://bugs.launchpad.net/ubuntu/+source/system-config-printer/+bug/546965 this is the issue here, so I'm waiting for ubuntu5 version of system-config-printer to roll out.


madbiologist (me-again) wrote :

It looks like the fix for bug #546965 is out.

imachine (m-jedrasik) wrote :

Yes, it seems that way, however I still can't print anything right now :) Test page prints, but the pdf from above now does not print at all.

https://bugs.launchpad.net/ubuntu/+source/system-config-printer/+bug/548752 it could be related to this bug, since I too am experiencing it.

imachine (m-jedrasik) wrote :

Now I experience this error when trying to print the above pdf file from the link:


Please let me know, this is frustrating :-)

I just tried to print that document and here, too, the image is missing. I attached another file (Abschlussarbeit.pdf) that has the same problem: the image (the blue logo) on page 1 doesn't print - neither with Evince 2.32.0 (from Ubuntu 10.10) nor with Evince 2.30.3 (from Ubuntu 10.4). Please note that this is by far the only example. At our site it is more the rule than the exception that images do not print. Sometimes even parts of graphics don't print (e.g. certain lines) while other parts of the same graphics do.

madbiologist (me-again) wrote :

I have successfully printed page 1 (including the blue logo) of the document attached to comment #13 with Ubuntu 10.10 on my Canon i965 (using the BJC 8200 Foomatic driver).

Matthias Jordan - What make and model is your printer?

Launchpad Janitor (janitor) wrote :

[Expired for evince (Ubuntu) because there has been no activity for 60 days.]

Changed in evince (Ubuntu):
status: Incomplete → Expired

Our main printer is an HP laserjet 4200 dtn.

madbiologist (me-again) on 2011-05-19
Changed in evince (Ubuntu):
status: Expired → Incomplete
status: Incomplete → New
status: New → Confirmed

Is there any news about this issue? If not: how can I help making progress here? I'm willing and able to compile relevant things and debug but, having absolutely no idea how this all works, I'd need a couple pointers. (Not the XKCD interpretation.)

Here is a bit more data: The issue is also prevalent with Evince 2.32.0 (from Ubuntu 11.4). An interesting observation might be that the sample PDF Abschlussarbeit.pdf prints okay to PDF. So when I open the file, choose /File/Print and print not to our laser printer but to a PDF file, the image is there.

This information is about Evince 3.4.0 from Ubuntu 12.04. I attached a file that Evince does not print correctly - the image is still missing. Further, I made some experiments:

0) printing Abschlussarbeit.pdf from Evince to a CUPS printer fails to print the image
1) "lpr Abschlussarbeit.pdf" prints the file correctly with image, using a remote CUPS server via IPP
2) printing Abschlussarbeit.pdf from Evince into a file Ausgabe.pdf prints correctly
3) printing Ausgabe.pdf from Evince fails to print the image (as expected)
4) printing Abschlussarbeit.pdf from Ad*be Reader to the same CUPS printer as in 0) prints the image correctly.
5) printing Abschlussarbeit.pdf usign gtklp prints the file correctly

Since lpr is the CUPS tool, I doubt it's a problem with CUPS or the printer driver. Further, both the third party tool and gtklp print the file correctly, using the same CUPS printer.

Also I tried

6) printing the document from Evince to a different printer (HP color laser) fails to print the image

Sebastien Bacher (seb128) wrote :

Thanks for the details, I don't have a printer to test but it's likely a poppler issue, would be useful to report it on https://bugs.freedesktop.org/enter_bug.cgi?product=poppler

affects: evince (Ubuntu) → poppler (Ubuntu)
Changed in poppler (Ubuntu):
importance: Undecided → High

This information is about Evince 3.4.0 from Ubuntu 12.04 using poppler 0.18.4-1ubuntu2 . I attached a file (Abschlussarbeit.pdf) that Evince does not print correctly - the image is still missing. Further, I made some experiments:

0) printing Abschlussarbeit.pdf from Evince to a CUPS printer fails to print the image
1) "lpr Abschlussarbeit.pdf" prints the file correctly with image, using a remote CUPS server via IPP
2) printing Abschlussarbeit.pdf from Evince into a file Ausgabe.pdf prints correctly
3) printing Ausgabe.pdf from Evince fails to print the image (as expected)
4) printing Abschlussarbeit.pdf from Ad*be Reader to the same CUPS printer as in 0) prints the image correctly.
5) printing Abschlussarbeit.pdf using gtklp prints the file correctly
6) printing the document from Evince to a different printer (HP color laser) fails to print the image

Since lpr is the CUPS tool, I doubt it's a problem with CUPS or the printer driver. Further, both the third party tool and gtklp print the file correctly, using the same CUPS printer.

This is also reported in https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/537970

Sebastien, thanks for the hint. I attached my information to https://bugs.freedesktop.org/show_bug.cgi?id=24828 so it can cuddle with the 67 other image related issues.

Created attachment 62104
Demo PDF that poppler fails to render including the image

Bug in comment #3 renders crap in Adobe Reader too, so i'd vote for broken document.

Sebastien Bacher (seb128) wrote :

Thanks, upstream replied that the document you added is misrendered by acroread as well and seems buggy

Changed in poppler:
importance: Undecided → Unknown
status: New → Unknown

Did upstream indicate why they think the document is buggy? I omitted most of the text to make the document smaller so if all you see is some capital letters and a PNG then you're seeing it right. I attached a screenshot of the Evince screen output which is exactly as it is intended to print.

Changed in poppler:
importance: Unknown → Medium
status: Unknown → Confirmed
Sebastien Bacher (seb128) wrote :

you can read the log on https://bugs.freedesktop.org/show_bug.cgi?id=24828, maybe you should comment there?

Created attachment 62423
Preview of Abschlussarbeit.pdf as intended to print

OK, just so people don't "vote" the document is broken I attached Abschlussarbeit.png, which shows how the document is supposed to print. What does in fact not print, though, is the PNG logo in the lower right corner. The text is kept to a minimum to make debugging easier.

And, seriously, if you take a look at the experiments I performed to narrow down the problem (comment #2 above), how can you think I post a bug for an obviously broken document? We've been having that problem for months at work with just about every document we try to print - generated by LaTeX, OOo, LibreOffice, you name it. There is always some image that does not print. And I tried to view and print the document with Adobe Reader, too, and if I write "Adobe Reader prints correctly", you can take my word for it.

If anybody can get me started on building the project, I'm glad to help.

The renderings I get from evince (master, with poppler master and
cairo master), ghostscript (9.05 and master) and mupdf (master) all
match the png you posted as attachment #62423.

I looked at the document after running it though:

  :; mupdfclean -d -a Abschlussarbeit.pdf Abschlussarbeit.pdfc

to make it readable. The only odd thing I found was that the ink was
set (via 0 g 0 G) multiple times in a row. That is redunant – even
redundantly redundant ☺ – but shouldn’t cause any harm.

Oddly, gs 9.05’s psdrgb device was unable to render the file; every
other output device I tried with gs 9.05 worked fine.

In any case, poppler master with cairo master renders correctly.

This leaves me wondering why the heck the document renders correctly on screen but Evince is not able to print it. I'm not really sure if I made myself clear here: The document (and every other document that has this problem) can be read correctly on screen with all images, but printing it results in missing images (e.g. the blue logo in Abschlussarbeit.pdf). This is exactly as the original bug description states.

So, any other idea as to why Evince cannot print the above PDFs? I know Launchpad states that only 3 people are affected. But my whole office has been having that problem for three years or so and most have already moved on to proprietary software. Because, you know, that works.

Please note I'm not just bitching around. I'm able and willing to help if anybody could get me started. Apparently it's not even easy for Evince developers to pinpoint the issue so a little help would be awesome.

Sebastien Bacher (seb128) wrote :

(Ccing Till who maintains cups in Ubuntu)

Hey Till, could you have a look if there is anything wrong on the cups side there? The rendering and print previews are fine but the printing leads to missing images

@Matthias: thanks for caring, we lack people knowing well the poppler, cairo stack to help there though, the upstream bug is a better place to move forward on that front ... they seem to suggest it does render fine with the current trunk of everything but as far as I understand rendering was not an issue, not sure if they tested printing as well

Changed in cups (Ubuntu):
assignee: nobody → Till Kamppeter (till-kamppeter)
importance: Undecided → High

seb128, I cannot reproduce this bug on Precise. I have Precise with all updates and I have printed Abschlussarbeit.pdf out of evince on three different printer types (PostScript, CUPS Raster, Foomatic/pxlmono) and the printouts are all correct, with the image.

I do not have Lucid at hand but there it is possible that images can be missing in printouts from evince, as older versions of Ghostscript have a bug which leads to images in some PDF input files being dropped.

Matthias, can you attach Ausgabe.pdf from comment #19? Can you also print it with "lpr Ausgabe.pdf"? Does it print correctly?

Till, I'm afraid I don't understand you. I already attached the file to Launchpad comment #19 (linked both in the comment and in the attachment list in the upper right hand side as "The file, that Evince prints w/o image") and in #19 I wrote that the PDF prints correctly using lpr.

Matthias, sorr.

I am assuming that the attached file is Abschlussarbeit.pdf. I have downloaded it and I have done the steps which you have written up in comment #19. For me the image always appears, under Precise (12.04) with all updates (cups-filters 1.0.18, cups 1.5.3, ghostscript 9.05, evince 3.4.0, poppler 0.18.4, cairo 1.10.2). I tried on both PostScript and non-PostScript printers.

So, once, can you check whether your system is up to date and second, can you create the file Ausgabe.pdf as described in comment #19 and attach it, so that I can compare it with Ausgabe.pdf as my evince generates it and try to print. This way we can find out in which step the file breaks.

Till, I have to apologize for a) using a super-stupid naming scheme for the two files that even I find confusing and b) for not getting that you're talking about the other file. Well.

I attached Ausgabe.pdf as generated by my Evince 3.4.0. This has been generated on an up-to-date Ubuntu 12.04.

Versions here are:
cups-filters 1.0.18-0ubuntu0.1
cups 1.5.3-0ubuntu1
ghostscript 9.05~dfsg-0ubuntu4
evince 3.4.0-0ubuntu1
libcairo2 1.10.2-6.1ubuntu3

Now I also lifted our laser printer to my office and printed Abschlussarbeit directly through the parallel port. You know what? The logo prints from within Evince.

This indicates that the GNOME print dialog does stuff entirely different from what lpr and gtklp do with remote CUPS servers. In all former cases the same (as in "==", not as in .equals()) remote printer hardware was used. (This was also the very hardware that prints the logo when attached to the parallel port.)

So that means that Evince in Precise prints just fine to a parallel port printer but not to a remote CUPS printer while gtklp and lpr print fine using the same remote CUPS printer that Evince fails to print to.

That lead me to a new hypothesis: the remote CUPS server or one of its subsystems is buggy; printing from gtklp and lpr works because the hardware printer, attached to the CUPS server using Ethernet, is accessed directly from gtklp and lpr while Evince talks to the CUPS server. An experiment (printing a job using Evince and gtklp) refuted this: both jobs appeared in the CUPS job queue.

What's also interesting is that the (failing) remote print job from Evince is listed as 1053k in the Size column in the CUPS jobs list for that printer while the gtklp job clocks in at 989k.

And the absolute super joke is that after reattaching the darn laser printer and killing two stale print processes (hung since March) the bug disappeared and the logo prints correctly out of Evince. This is even more hilarious if you consider that this wasn't the first time we power-cycled the printer and the problems began long before March this year. I'm positive that the PNG printing problem will reappear. Until then I'm not able to repro this any further.

Fun fact: after #41, a colleague printed the file Abschlussarbeit.pdf with Evince 3.2.1 to the same CUPS and hardware printer as above and the logo did not print. The file does, though, print with gtklp and the CUPS lpr program. I'll have to wait for another colleague to return from a business trip so we can try that on another Precise machine.

I also cannot reproduce the bug with your new attachment.

Note that if your printer is connected to another machine, only evince runs on your local Linux or Mac OS X machine, the print filtering is done on the remote machine. Is the remote machine also Precise? If it runs an older Ubuntu version, there is most probably a bug which is fixed in Precise. Try to upgrade the remote machine to Precise then.

Note also that Precise ships evince 3.4.0. The machine with evince 3.2.1 runs an older Ubuntu version, most probably Oneiric. The transition from evince 3.2.1 to 3.4.0 can have improved the situation, too.

I can comment on this too, Evince prints a document partially, it is missing the extreme upper and lower parts on paper but not in the preview. In XPDF the whole document IS printed! So one can conclude that it is not the printer driver and not the printer, in my case a HP 8150, unless of course XPDF uses a different approach to print the document, whatever setting I try in the preview. The next weird thing is that Evince always prints an extra empty page, no matter what I try to set.
In Evince, embedded photos show broken up in several parts with thin white lines in between them, this, however is not always the case so must depend on the original embedded material used. In XPDF that is not the case with the same material. Needless to say that Adobe's viewer is doing this right too.
If this is a case of Evince 2.30.3 in Lucid, my question is: Why can't this be updated? I know...switch to Precise...but Precise has the problem of not willing to use my Epson V500 scanner and Lucid does... And Lucid is also still LTS...

Oops... Evince 3.3 in Precise (on my laptop) still has the same broken embedded photos as I see in Lucid. So still no joy.

Changed in cups (Ubuntu):
status: New → Confirmed

Reproduced on VM.

Rouven Sacha (rouvensacha) wrote :

I can confirm this bug with a current 12.04 setup. Evince shows the files just fine but the print (on some printers) doesn't include the images.

Adobe Reader prints the files happily on the same printers.

Evince 3.10 from 14.04 also prints the files just fine.

Daniel Holbach (dholbach) wrote :

<tkamppeter> dholbach, the problem seems to be Poppler when I look at the bug report but it is not very clear herewhich change on Poppler fixed it.

rouvensacha, please take a file which shows the problem for you (attch it to this bug report if it is not already attached), then do the usual steps to print it, but as printer choose "Print to file". Then choose PDF as output format and print. Does the resulting PDF file (please also attach it to this bug) show the pictures? Always? or are there some PDF viewers with which you can see the pictures and others with which you do not see them? Try at least evince and gs, but also others like Adobe Reader.

Also go to https://wiki.ubuntu.com/DebuggingPrintingProblems and, with normal printing of your file to a real printer, follow the instructions of the sections "CUPS error_log" and "Capturing print job data".

Attach all the requested files one by one, do not compress them and do not pack them together.

Cysioland (cysioland) wrote :

Still occurs to me on Ubuntu 15.10. "Print to file" is also without images.

Cysioland (cysioland) wrote :

lpr prints everything correctly

D J Gardner (djgardner) wrote :

Tracked down this bug on meeting the same problem on (fully patched) 14.04 LTS.
Print via lpr is fine, via xpdf all is fine, but evince does not print part of embedded pdf logo (the missing bit is pale blue... is there a connection here??)
Printing in greyscale does not bring back the missing logo.

D J Gardner (djgardner) wrote :

Further to above...
Print to file (tested with pdf, ps and svg) similarly partially removes the logo, which I count as clear evidence the bug is not related to CUPS in any way.

Changed in cups (Ubuntu):
status: Confirmed → Invalid
Changed in gtk+3.0 (Ubuntu):
status: New → Confirmed

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/314.

Changed in poppler:
status: Confirmed → Unknown
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.