Evince doesn't print PDF files

[Gabriel Acevedo H.]

Binary package hint: evince

Hello,

I can't print PDF files, using Evince Document Viewer, in Ubuntu 8.04 LTS. Note that in Ubuntu 7.10 I used to print with no problems using Evince.

I do can print using OpenOffice or xPDF (which uses lpr), but Evince just won't. No error messages, no printer icon in gnome-panel, just... nothing.

Information about my system:

gacevedo@commodore:~$ lsb_release -rd
Description: Ubuntu 8.04
Release: 8.04

gacevedo@commodore:~$ uname -a
Linux commodore 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686 GNU/Linux

gacevedo@commodore:~$ apt-cache policy evince
evince:
  Installed: 2.22.1.1-0ubuntu1
  Candidate: 2.22.1.1-0ubuntu1
  Version table:
 *** 2.22.1.1-0ubuntu1 0
        500 http://cl.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

My printer is HP Deskjet F380 All-In-One (HP DeskJet F300 Foomatic/hpijs, hpijs 2.8.2).

Thanks in advance for any hint or workaround.

ProblemType: Bug
Architecture: i386
Date: Tue May 6 01:55:01 2008
DistroRelease: Ubuntu 8.04
ExecutablePath: /usr/bin/evince
Package: evince 2.22.1.1-0ubuntu1
PackageArchitecture: i386
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: evince
Uname: Linux 2.6.24-16-generic i686

[Marcel Stimberg (marcelstimberg)]

Hi,
thanks for your bug report. Please provide some additional details:
* Does printing not work for _all_ documents or just for some documents?
* Does printing to a file work?

[Gabriel Acevedo H. (gacevedo)]

Hey there,

Thanks for replying.
I've just realized that there are just a few files which I can not print with Evince. Weird thing is that xpdf can print them all while Evince can not. Printing to a file works, slowly, but works.

I'm attaching a file, so you can play with it. I received it by mail from a teacher at university, so I have no clue how did she create it.

Thanks again.

[Marcel Stimberg (marcelstimberg)]

Confirming for the given document. Printing to a file works only for PDF, while printing to PS does not create any output (but no crash, no error messages). It might be a duplicate of the other printing bugs listed for evince, but I don't have time to look into that right now...

[Jean-Baptiste Lallement (jibel)]

Printing to PS works too but it takes a lot of time to generate the output. And the quality is very very low.

[Simon (simsiem)]

I have the same problem:

  Printing of some PDF files to a PostScript printer is
  very very very slow and produces a poor quality. It looks rasterised.

I did some tests with LaTeX producing the PDF file and found the following: I can use the same LaTeX source only switching the "\usepackage[T1]{fontenc}" line creating a working and a not working PDF file. I tested it with the "Print to file (PS)" option in the printing dialog, thus it seems not to be related to any specific printer. I attached both PDF files and the LaTeX source. Both documents only have one page without graphics. Thus it seems to be a problem related to the font encoding. And some component switches in a rasterising mode.

Regards, Simon

[Simon (simsiem)]

How can I attach several files at once?

[karenin (einstand)]

I have the same issue.

[Mark Darbyshire (markdarb)]

I have the same issue. When I try to print the evince process jumps up to 100% CPU usage (or rather 50% for me since I have a dual core CPU).

On two occasions, however, the printer printed an error. The first time this was presumably from a normal attempt to print. The second time it was when I tried to print the print preview. The printed error is as follows:

ERROR NAME;
   limitcheck
COMMAND;
   LZWDecode
OPERAND STACK;
   --filetype--
   --nametype--
   --dicttype--

I can also confirm that of the two pages Simon submitted, the I'm able to print the one that supposedly prints, but unable to print the one that supposedly doesn't.

According to the printer configuration tool, my printer's make and model is "Brother HL-5250DN BR-Script3". I connect to it using Ethernet via a router. It'- Device URI is "socket://192.168.1.100:9100".

I'm using Evince Document Viewer 2.22.2. I have no problems printing in other programmes. Today is the first time I've been unable to print a PDF in Evince.

When Evince fails to print anything, the document never appears in the printing queue.

I've tried connecting to the printer using USB. The document appears in the printing queue briefly but does not print.

I also tried using a Canan Pixma iP4300. Again Evince used 100% for a period of time. Then the document appeared in the print queue. It did print, but at an unacceptably low quality (very blurred).

If I try to print other pdf documents (such as the "working PDF") Evince does not hog CPU, and the document prints very promptly.

Note: the document that I was first having trouble with is "Tutorial 1 Questions" at http://www.math.canterbury.ac.nz/material/MATH109/08/S2/C/?s=5 and I do not have any problems with the second tutorial listed on that page.

[Robert (robrwo)]

I also have this problem, for some pdf files (most will print with no problem). CPU usage goes to 100% and nothing shows up in the print queue. Sometimes evince crashes and I cannot even close it without using xkill.

Print preview causes the same problem.

Unfortunately I cannot post the documents in question. (I used to be able to print this pdf from Ubuntu Gutsy.)

If I print using xpdf, it seems to go to the printer queue but takes forever to process. So I wonder if this is a cups issue.

[Sebastien Bacher (seb128)]

could somebody having the issue open a bug against poppler on bugs.freedesktop.org where people writting the code will read it?

[Simon (simsiem)]

Created an attachment (id=18774)
The LaTeX source file

If I use the T1 fonts in LaTeX, Evince cannot print the PDF files any more. Actually printing takes very long and outputs a rastered image. With the Adobe Reader everything works fine. In the related Ubuntu bug report (https://bugs.launchpad.net/ubuntu/+source/evince/+bug/227186), Sebastian Bacher asked to open a bug report for poppler. Actually I'm not sure, whether this is a bug in poppler or in cairo. There is another related bug report in Launchpad (https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/150187).

Here are the details:

I created a small sample LaTeX file (test.tex), which demonstrates the bug. If I compile it without the "fontenc" package using pdflatex, everything works fine in Evince. I named this PDF file "good.pdf". If I compile it with the "fontenc" package (and the option "T1", which uses fonts of a certain LaTeX font encoding), pdflatex creates a PDF file ("wrong.pdf") that Evince cannot print correctly any more. I also attach the printing output of Evince, when using the PDF printer. I named these file "good.printed.pdf" and "wrong.printed.pdf".

The following graphic illustrates the described setting.

              test.tex

pdflatex: / \

      good.pdf wrong.pdf

Evince: | |

 good.printed.pdf wrong.printed.pdf

Since the problem is somehow related to fonts, I also compile the font information of pdffonts and the Adobe Reader in the following:

pdffonts on good.pdf:
  name type emb sub uni object ID
  ------------------------------------ ----------------- --- --- --- ---------
  FYHDIM+CMSSBX10 Type 1 yes yes no 4 0
  PTMTFG+CMR10 Type 1 yes yes no 5 0

pdffonts on good.printed.pdf:
  name type emb sub uni object ID
  ------------------------------------ ----------------- --- --- --- ---------
  UFQSLH+f-1-0 Type 1C yes yes yes 10 0
  ZRSKVS+f-0-0 Type 1C yes yes yes 8 0

pdffonts on wrong.pdf:
  name type emb sub uni object ID
  ------------------------------------ ----------------- --- --- --- ---------
  [none] Type 3 yes no no 4 0
  [none] Type 3 yes no no 5 0

pdffonts on wrong.printed.pdf:
  name type emb sub uni object ID
  ------------------------------------ ----------------- --- --- --- ---------

Adobe Reader on good.pdf:
  CMR10 (Eingebettete Untergruppe) [engl: embedded subgroup]
    Typ: Type 1
    Kodierung: Mitgeliefert [engl: Coding: shipped/supported]
  CMSSBX10 (Eingebettete Untergruppe)
    Typ: Type 1
    Kodierung: Mitgeliefert

Adobe Reader on good.printed.pdf:
  f-0-0 (Eingebettete Untergruppe)
    Typ: Type 1
    Kodierung: Benutzerdefiniert [engl: Coding: User defined]
  f-1-0 (Eingebettete Untergruppe)
    Typ: Type 1
    Kodierung: Benutzerdefiniert

Adobe ...

[Simon (simsiem)]

Created an attachment (id=18775)
pdflatex creates this PDF file, if I omit the fontenc package

[Simon (simsiem)]

Created an attachment (id=18776)
The printing output of Evince for good.pdf

[Simon (simsiem)]

Created an attachment (id=18777)
pdflatex creates this PDF file, if I use the T1 fonts

[Simon (simsiem)]

Created an attachment (id=18778)
The printing output of Evince for wrong.pdf

[James H. Cloos Jr. (cloos-jhcloos)]

> pdffonts on wrong.pdf:
> name type emb sub uni object ID
> ------------ --------- --- --- --- ---------
> [none] Type 3 yes no no 4 0
> [none] Type 3 yes no no 5 0

Note the Type3 fonts. That means that you ended up with metafont-
rendered bitmap fonts rather than type1 fonts. Specifically the
ec fonts which are typically found at:

    /usr/share/texmf-dist/fonts/source/jknappen/ec/

You may prefer to get the LatinModern fonts, outline fonts which cover
the subset of ec text-font glyphs which LaTeX uses. (The math fonts,
when using lm, are the same CM Type1 fonts your good.pdf example would
have used, had it had any math.)

That said, it is indeed a bug that evince cannot correctly handle Type3
bitmap fonts. And probably means that it also cannot handle Type3 vector
fonts.

Whether the bug is in evince, poppler, cairo is a good question.

Cairo has had some recent changes which may be relevant. Since you point
at launchpad, I presum you use Ubuntu; you, therefore, are probably using
rather old versions of poppler and cairo....

[Simon (simsiem)]

I agree: The main problem is, that evince/poppler/cairo cannot print Type 3 fonts. But

 - I regularly receive or download some PDF files with Type 3 fonts

 - Evince _can show_ them correctly on the screen
   (with each letter markable on its own)

 - Adobe Reader can show them correctly on the screen and
   print them to PostScript

 - Evince cannot print them.

And if I look at many bug reports in the Internet, I'm not the only one receiving such documents. (Actually there are much more bug reports I consider to be related as those two linked in my original posting.)

So, thanks for pointing out the LaTeX behaviour. Indeed, the EC package can solve it as it switches to Type 1 fonts. But this is only of help, if I have the LaTeX sources.

Again thanks James and best regards,

Simon

[James H. Cloos Jr. (cloos-jhcloos)]

xpdf/poppler (via Gentoo’s ebuild) can print wrong.pdf to PS in an
optimal way (the fonts are converted to PS Type3 fonts and the strings
are shown).

Ghostscript 8.63’s cairo backend handles wrong.pdf as well as expected:
all of the glyphs are output as filled paths. (The cairo backend is
advertized to do just that with any fonts). The filled paths, though,
look like squares making up the individual pixels of the bitmaps.

GS 8.63’s pdfwrite does a much better job than you got from 8.61:

  :; pdfinfo wrong.printed.pdf
  Producer: GPL Ghostscript 8.61
  CreationDate: Tue Sep 9 12:03:47 2008
  ModDate: Tue Sep 9 12:03:47 2008
  Tagged: no
  Pages: 1
  Encrypted: no
  Page size: 595 x 842 pts (A4)
  File size: 299281 bytes
  Optimized: no
  PDF version: 1.4

  :; pdfinfo wrong_pdfwrite.pdf
  Producer: GPL Ghostscript 8.63
  CreationDate: Fri Sep 12 13:54:23 2008
  ModDate: Fri Sep 12 13:54:23 2008
  Tagged: no
  Pages: 1
  Encrypted: no
  Page size: 595.28 x 841.89 pts (A4)
  File size: 7804 bytes
  Optimized: no
  PDF version: 1.4

Said output also looks better when viewed on screen.

Also, poppler’s pdftops seems to work well on wrong.pdf (as of poppler
commit 217c0d1f80a78713977a7bfbe680fce90f1c6b36). As well as xpdf/poppler
does.

This suggests that if the bug is in poppler it has been fixed, or that
the bug in in evince.

Unfortunately, I cannot test in evince because I seem to have updated
poppler and evince but not poppler-bindings, which prevented evince’s
configure from finding libpoppler. [SIGH]

I’ll have to update again and try then. Probably not until Sunday,
though.

[Brandon Moore (bmmoore)]

pdftops alone fails on wrong.pdf.
(Version 3.02, from poppler-utils 0.6.4-1ubuntu1 in Ubuntu 8.04).
Instead of characters I get see squares of garbage.
With the -level1 option the output seems fine.
I haven't tried a more recent release yet.

[Brandon Moore (bmmoore)]

Created an attachment (id=18985)
pdftops wrong.pdf <- version from poppler-utils 0.6.4-1ubuntu1 amd64

[Brandon Moore (bmmoore)]

Created an attachment (id=18986)
pdftops -level1 wrong.pdf <- version from poppler-utils 0.6.4-1ubuntu1 amd64

This one looks ok.

[James H. Cloos Jr. (cloos-jhcloos)]

I am out of X right now, but I am pretty sure that pdftops/poppler from
poppler git master of a few days ago gave reasonable output. I can say
that, for each of levels 1, 2 and 3, it generates Type3 PostScript fonts
for each of the Typd3 PDF fonts and outputs the text using show-type ops.

The biggest difference between the level1 and level2 output is that l1
uses hex and level2 uses ascii85 encoding for the images which make up
the type3 fonts. Level3 only adds better support fir CID-keyed fonts
over the level2 output.

[Time passes...]

I ran those ps files thru gs -sDEVICE=pbm -r75 (which creates ascii PBM
files), opened them in emacs and removed the newlines after each 64-
character long line, thereby having one line of 0s and 1s for each pixel
row of the image. That shows that gs 8.63, at least, can handle the PS
output by pdftops/poppler (of git master) just fine.

I suspect, then, that this part of your problem is due to the outdated
version of poppler in the version of Ubuntu you have installed.
(poppler 0.6.4 is OLD.)

Git master poppler and cairo do not fully fix the problem when using
evince to print.

Evince generates new PDF or PS using cairo when printing. The resulting
files are ugly.

I found that evince needed tens of minutes to print wrong.pdf to a ps
file on my 1GHz PIIIM. The resulting ps has 847 fallback images of
the form:

  % Fallback Image: x=149, y=129, w=3, h=2 res=300dpi size=351
  [ 0.24 0 0 0.24 149 660.839983 ] concat
  /DeviceRGB setcolorspace
  8 dict dup begin
    /ImageType 1 def
    /Width 13 def
    /Height 9 def
    /BitsPerComponent 8 def
    /Decode [ 0 1 0 1 0 1 ] def
    /DataSource currentfile /ASCII85Decode filter /LZWDecode filter def
    /ImageMatrix [ 1 0 0 -1 0 9 ] def
  end
  image
  J3Vsg3$]7K#D>EP:q1$o*=mro@So+\<\5,H7Uo7+~>Q
  q 0 0 612 792 rectclip

If you use something like pdftk(1) to uncompress the PDF evince
generates you find similar output there, too.

I'm not sure where the fault lies in terms of evince, poppler or
cairo. Evince probably should use cairo's userfont API. It
probably should also use poppler's pdftops code for generating
PS from PDF, and pass PDF thru as is when generating PDF from PDF.

IE, evince probably ought to have document-backend-specific routines
for generating PS and PDF for printing.

I *think*, then, that -- at least when using current tip versions --
the bug is in evince, not in poppler.

[Adrian Johnson (ajohnson-redneon)]

(In reply to comment #11)
> I found that evince needed tens of minutes to print wrong.pdf to a ps
> file on my 1GHz PIIIM. The resulting ps has 847 fallback images of
> the form:
>
> % Fallback Image: x=149, y=129, w=3, h=2 res=300dpi size=351
> [ 0.24 0 0 0.24 149 660.839983 ] concat
> /DeviceRGB setcolorspace
> 8 dict dup begin
> /ImageType 1 def
> /Width 13 def
> /Height 9 def
> /BitsPerComponent 8 def
> /Decode [ 0 1 0 1 0 1 ] def
> /DataSource currentfile /ASCII85Decode filter /LZWDecode filter def
> /ImageMatrix [ 1 0 0 -1 0 9 ] def
> end
> image
> J3Vsg3$]7K#D>EP:q1$o*=mro@So+\<\5,H7Uo7+~>Q
> q 0 0 612 792 rectclip
>
> If you use something like pdftk(1) to uncompress the PDF evince
> generates you find similar output there, too.
>
> I'm not sure where the fault lies in terms of evince, poppler or
> cairo. Evince probably should use cairo's userfont API. It
> probably should also use poppler's pdftops code for generating
> PS from PDF, and pass PDF thru as is when generating PDF from PDF.

It is a limitation of the cairo backend of poppler that it can't print Type 3 fonts nicely. When cairo 1.8 is released with the new user-font API it will be possible to fix this in poppler. Cairo user-fonts are embedded in PS/PDF as a Type 3 font.

[James H. Cloos Jr. (cloos-jhcloos)]

> It is a limitation of the cairo backend of poppler that it can't print
> Type 3 fonts nicely. When cairo 1.8 is released with the new user-font
> API it will be possible to fix this in poppler. Cairo user-fonts are
> embedded in PS/PDF as a Type 3 font.

Although I generally use xpdf/poppler for reading PDFs and evince only
for forms, I am available to help test if you are willing to increase
poppler master’s required cairo version to either cairo/master or the
current pre-release (1.7.6) and start using the user-font API on master
now rather than after cairo makes its 1.8.0 release.

(I find this to be an intriguing bug to quash.)

[Albert Astals Cid (aacid)]

Not right now, we are in process of converting trunk into stable so you'll have to wait until October 9 that is when trunk will be open again for non bugfixes

[der_vegi (m-may)]

Maybe this bug is related to https://bugs.freedesktop.org/show_bug.cgi?id=12769 ?

[junior (olav-ekkje)]

Having the same issue! And it's veeery annoying!

[Sebastien Bacher (seb128)]

did anybody send that upstream yet?

[Simon (simsiem)]

I filled a bug report for poppler (http://bugs.freedesktop.org/show_bug.cgi?id=17497). However, the responses were divergent. I could not find out, whether the bug is in Evince, poppler, or cairo. Maybe you can read the important information from the discussion there.

Thanks, Simon

[Adrian Johnson (ajohnson-redneon)]

Fix in git.

[Sebastien Bacher (seb128)]

the bug has been fixed upstream now

[Sebastien Bacher (seb128)]

the new version is in jaunty

[junior (olav-ekkje)]

Any way of getting this fix in Hardy? Was it a cairo-bug?

[Sebastien Bacher (seb128)]

the bug was a cairo one and not an evince issue

[bixejo (bixo-bixejo)]

Did anyone find a way to fix this issue in 8.04 without upgrading?

I've to spend a lot of work after any upgrade, so I would appreciate if someone would be able to tell me how to do this. It's really annoying, indeed...

[bixejo (bixo-bixejo)]

Dummy (forgot to check "E-mail me about changes to this bug report", sorry.)

[Simon (simsiem)]

I'd like to see a fix for 8.04 as well, because I will stay on the LTS release. It's always a bit better and longer supported.

[bixejo (bixo-bixejo)]

Another reason for me to stay on 8.04 is that I tried to upgrade and got a warning saying that there were no NDIVIA driver available for 8.10, so I'm afraid I'm bounded to 8.04 till a new version with this driver available is released...

[ricardisimo (ricardisimo)]

Interestingly, evince will print frame borders in a document, but not the text within the frames. This doesn't seem to be a problem with PDFs that I generate here on my own comp, but only with PDFs that some people send me. Anything I can do to help here?

I'm on Ubuntu 8.10, using evince version 2.24.1. Thanks.

[sz (szeder)]

Unfortunately, the situation is by no means fixed in Jaunty RC.

Opening Simon's good.pdf (https://bugs.launchpad.net/ubuntu/+source/evince/+bug/227186/comments/7) and printing it to pdf with Jaunty RC's evince takes approx. 0.9 sec CPU time and the produced output pdf is approx. 7kB.

Opening Simon's wrong.pdf (https://bugs.launchpad.net/ubuntu/+source/evince/+bug/227186/comments/8) and printing it to pdf takes approx. 1.6 sec CPU time and the produced output pdf is 1.5MB (yes, _mega_bytes). Neither evince nor gv could open the resulting pdf.

The difference in CPU usage seems not much, but the documents in question are quite short. Making a 10 pages long document from Simon's tex source with some copy-pasting and printing it to pdf will take approx. 1 sec CPU time without T1 fonts and 6.5 sec with T1 fonts, and the resulting pdfs are 20kB vs. 16MB.

The CPU usage is even worse when opening the print preview. In case of Simon's pdf, it takes 1 sec CPU time to open good.pdf and display its print preview, but takes 21 sec to do the same with wrong.pdf. With the 10 pages long document it's 2 sec vs. 223 sec. The print preview looks as expected for the documents without T1 fonts, but looks terrible with T1.

[jeff (jeff-barth-deactivatedaccount)]

I'm having this problem on Ubuntu 9.10. I print a PDF from my instructor, the 'activity' light on the printer blinks slowly for a while (same as for any print job), then nothing. The activity light returns to solid on, and no output. I have an Apple LaserWriter Select 360. Plain text files seem to print OK.