sometimes it never prints out any page and hangs

Can you please attach a PDF document which causes this problem. Also, what is the make and model of your printer? Is it connected locally (eg. via USB) or on a network?

Yes, sure. My printer is hp laserjet 1018. it is connected locally via USB.
I attempted to print djvu file (151 pages).

http://dl.dropbox.com/u/4509280/Enterprise_4grammer.7z

On Tue, Feb 23, 2010 at 5:55 AM, madbiologist <email address hidden> wrote:

> Can you please attach a PDF document which causes this problem. Also,
> what is the make and model of your printer? Is it connected locally
> (eg. via USB) or on a network?
>
> ** Changed in: evince (Ubuntu)
> Status: New => Incomplete
>
> --
> sometimes it's never print out any page and hangs on
> https://bugs.launchpad.net/bugs/525161
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “evince” package in Ubuntu: Incomplete
>
> Bug description:
> Binary package hint: evince
>
> sometimes it's never print out any page and hangs on
>
> ProblemType: Bug
> Architecture: amd64
> Date: Sun Feb 21 13:33:00 2010
> DistroRelease: Ubuntu 9.10
> ExecutablePath: /usr/bin/evince
> InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
> NonfreeKernelModules: fglrx
> Package: evince 2.28.1-0ubuntu1.2
> ProcEnviron:
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> ProcVersionSignature: Ubuntu 2.6.31-20.57-generic
> SourcePackage: evince
> Uname: Linux 2.6.31-20-generic x86_64
> XsessionErrors:
> (gnome-settings-daemon:4586): GLib-CRITICAL **: g_propagate_error:
> assertion `src != NULL' failed
> (nautilus:4621): Eel-CRITICAL **: eel_preferences_get_boolean: assertion
> `preferences_is_initialized ()' failed
> (polkit-gnome-authentication-agent-1:4652): GLib-CRITICAL **:
> g_once_init_leave: assertion `initialization_value != 0' failed
> (gnome-panel:4617): Gdk-WARNING **:
> /build/buildd/gtk+2.0-2.18.3/gdk/x11/gdkdrawable-x11.c:952 drawable is not a
> pixmap or window
> (firefox:5009): GLib-WARNING **: g_set_prgname() called multiple times
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/evince/+bug/525161/+subscribe
>

--
Sincerely,
Batumongke

I can confirm this bug on Ubuntu 9.10 "Karmic Koala". I attempted to use evince 2.28.1-0ubuntu1.2 to print the attached djvu file to my Canon i965 (installed as BJC 8200+foomatic drivers), attached locally via USB. My libcairo2 is version 1.8.8-2ubuntu1.1.

After pressing print, evince's printing progress bar advances to 100% and then pauses. At this point I thought it had hung, however the progress bar disappeared after about 20 or 30 seconds. Opening my printer status showed the document with a size of 60313k and a status of "Processing". Also my CPU usage was at 100% (I have a single-core CPU). I went shopping and when I returned over 3 hours later my printer had still not printed anything and the document status was still "Processing". CPU usage was still at 100%. At this point I canceled the job, however CPU usage stayed at 100% until I closed the printer status window.

I tested printing the attached djvu file again on Ubuntu 10.04 "Lucid Lynx" alpha 3, with evince 2.29.91-0ubuntu1, and updated to the latest versions of poppler (0.12.4-0ubuntu1) and libcairo2 (1.8.10-2ubuntu1).

The results were identical except that the document eventually printed after 5 hours. I'm leaving the bug confirmed as nobody wants to wait 5 hours to print a document, and nor should they be expected to. Something is definitely wrong somewhere - this is almost as bad as the document not printing at all.

Not reproducible in Trusty.

I tested printing the attached djvu file again on Ubuntu 14.04 "Trusty Tahr" with evince 3.10.3-0ubuntu10.1, poppler 0.24.5-2ubuntu4.1 and libcairo2 1.13.0~20140204-0ubuntu1. Opening my printer status showed the document with a size of 60313k and a status of "Processing". The document had not begun to print after 17 minutes, with one of my 4 CPU cores still at 100% usage.

madbiologist, thanks for testing to this issue. I tested Printing to File (PDF), which works perfectly fine. Are you testing to a physical printer?

madbiologist, can you tell us which printer are you using and attach the PPD file of your print queue (/etc/cups/ppd/*.ppd)?

Please also follow the instructions of the section "CUPS error_log" on https://wiki.ubuntu.com/DebuggingPrintingProblems

Yes, I am printing to a physical printer. It is a Canon i965.

usb://Canon/i965?serial=438fcb
Canon i965 - CUPS+Gutenprint v5.2.10-pre2

relevant lsusb output is:

Bus 001 Device 004: ID 04a9:1088 Canon, Inc. i965
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

sudo usb_printerid /dev/usb/lp0
GET_DEVICE_ID string:
MFG:Canon;CMD:BJL,BJRaster3,BSCCe;SOJ:TXT01;MDL:i965;CLS:PRINTER;DES:Canon i965;VER:1.09;STA:10;POS:4002404807341F;

sudo usb_printerid /dev/usb/lp1
Error: No such file or directory: can't open '/dev/usb/lp1'

lpinfo -v output is attached

The document printed after an hour and twenty minutes. I've attached the error log after it began printing, although it wasn't updated after sending the print job.

Till Kamppeter, thanks for checking into this.

I just wanted to add a few data points to this issue.

In both Trusty and Vivid, printing to file (PS) https://bugs.launchpad.net/ubuntu/+source/evince/+bug/525161/+attachment/4284552/+files/Grammar%204.djvu took a few seconds.

However, in Vivid the conversion of this PS file to PDF via either Evince or ps2pdf took ~2 hours.

In Vista, if one takes this resultant PDF from Vivid and prints to XPS via Adobe Reader X, that takes ~10 minutes.

In Trusty, If one opens the resultant PDF in Evince and attempts to print to file (PDF) the preparing to print message took minutes to make 1 page of progress. However, it ultimately finished within 10 minutes.

Overall, given the resultant PDF is so massive for a PDF (100MB+) it's not a shocker it's taking so long to permute through all these different printing methods.

Hence, it may be helpful to finely scope this issue to either physical printer (and further to specific printer mfg.+model), or one conversation hop printing to file, e.g. ps to PDF, or how djvu to ps filesize goes from 6.5MB to ~62MB (if that's even a bug, as I'm not aware of the spec details). Scoping this report to printing to file allows a wider testing audience, saves on wasted printing paper, may more finely focus the issue to something more manageable for a developer, etc. However, I defer to your opinion on printing issues.

What do you think?

If the pure file conversion from PS to PDF (not printing) takes 2 hours (in evince "Print to file", format PDF, or ps2pdf on the command line) then there is a problem with the file converter in use concerning the conversion process or the PS file is extremely awkward (in this latter case direct printing on a native PostScript printer can also take long time or even fail).

What needs to be tested is what step actually takes too long time. So please do a printing/converting operation which takes too long and while it is running, run the "top" command in a terminal window. Which process is at the top of the list?

"Print to file" in evince 3.10.3-0ubuntu10.1 on Trusty only has an option to print to a PS file, so I did this, then ran ps2pdf.

Running the "top" command shows that gs from the ubuntu USER is at the top of the list with 100% use of one of my four CPU cores (single CPU state/separate CPU states can be toggled by pressing "1" while top is running). SHaRed memory was fixed at 3776 KiB, while VIRTual memory size and RESident memory size steadily increased to over 100000 KiB each after 10 minutes and continued to steadily increase to over 200000 KiB before the conversion completed after 1 hour and 17 minutes.

Unless I am mistaken, gs is ghostscript. The ghostscript version on Ubuntu 14.04 "Trusty Tahr" is 9.10~dfsg-0ubuntu10.2. However not that Christopher's conversion on Vivid also took ~2 hours. The ghostscript version on Ubuntu 15.04 "Vivid Vervet" development version is 9.14~dfsg-0ubuntu4

"However not that..."="However note that..."

Seems that a Ghostscript upstream bug has to get filed then (on http://bugs.ghostscript.com/).

Sending the PostScript file directly to a native PostScript printer, for example using the command

nc -w1 <IP address of printer> 9100 < Grammar\ 4.ps

leads to a printout in a reasonable time (2-3 pages quickly one after each other, then 5 seconds pause, 2-3 pages again and so forth).

This means that the PostScript IS awkward, but GhostScript is really TOO slow, meaning that there is room for improvement/fixing in Ghostscript.

Independent of this, the djvu software used by evince needs improvement, too, once it should generate better, easier to process PostScript, and second it should be able to directly convert djvu into PDF, as PDF is THE standard format for printable documents under all operating systems (please consider reporting an upstream bug here, too.

Reported upstream at http://bugs.ghostscript.com/show_bug.cgi?id=695778

Filed https://bugzilla.gnome.org/show_bug.cgi?id=742559 regarding evince producing an awkward PS file.

Filed https://bugzilla.gnome.org/show_bug.cgi?id=742561 regarding evince being unable to print a djvu file directly to a PDF file.

This bug was fixed in the package ghostscript - 9.15+dfsg-0ubuntu2

---------------
ghostscript (9.15+dfsg-0ubuntu2) vivid; urgency=medium

  * 020150413_3e71154_pdfwrite_optimise_pdf_foget_resource_with_charproc_resources.patch:
    Fixed a long delay caused when Ghostscript converts PostScript files to PDF
    where the PostScript comes from evince when printing a displayed DjVu file
    (LP: #525161, Upstream bug #695778).
 -- Till Kamppeter <email address hidden> Mon, 13 Apr 2015 18:37:51 -0300

Printing to djvu file to PS was near instantaneous in Bionic.