Bug 24828

Summary: Pages from image based PDF do not display
Product: poppler Reporter: Carlos Garcia Campos <carlosgc>
Component: cairo backendAssignee: poppler-bugs <poppler-bugs>
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Bug Depends on: 27456    
Bug Blocks:    
Attachments: Demo PDF that poppler fails to render including the image
Preview of Abschlussarbeit.pdf as intended to print

Description Carlos Garcia Campos 2009-10-31 07:27:01 UTC
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:

http://damonlynch.net/evince-problem.pdf"
Comment 1 Carlos Garcia Campos 2010-01-26 10:42:32 UTC
This is another bug in CairoOutputDev::drawImageMaskPrescaled().
Comment 2 Matthias Jordan 2012-05-25 08:35:28 UTC
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
Comment 3 Matthias Jordan 2012-05-25 08:37:24 UTC
Created attachment 62104 [details]
Demo PDF that poppler fails to render including the image
Comment 4 Albert Astals Cid 2012-05-25 09:45:35 UTC
Bug in comment #3 renders crap in Adobe Reader too, so i'd vote for broken document.
Comment 5 Matthias Jordan 2012-06-02 08:26:16 UTC
Created attachment 62423 [details]
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.
Comment 6 James Cloos 2012-06-02 10:57:39 UTC
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 [details].

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.
Comment 7 GitLab Migration User 2018-08-21 10:39:59 UTC
-- 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.

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.