I've been under ubuntu for nearly 10 years now, there are some problems that have thick skin! One of them, the slow printing delay problem, I never could solve! Today I start printing 20 copies of a 1 page pdf document, after half an hour nothing happened! I search for solutions on the net since years, but found any. I'm sure that it is not brand or model related problem, since I tested many printers from different brands, it seems that the raw file generated for the printer is very big, takes long time to be generated and to be transmitted to the printer.

I wonder if we could find some workarounds in this post, in cmdline, or at least, identify what's wrong, at which process it stucks, I know almost nothing in cmdline printing, can you please give some cmd lines to test and debug printing process.

Edit:

It seems that printing a single page one time give no delays, but if I try to print say, 20 copies of the same page, it seems that it's generating the whole 20 pages, thus giving a very long delay.

Edit 2: Here is my debug info: http://pastebin.com/yZFgP66v

Edit 3: Always after rebooting, the printing starts at boot process (I understand thus that it is a CPU issue!)

  • I personally haven't experienced this. – Android Dev Oct 22 '16 at 11:35
  • This seems like a CUPS issue not really Ubuntu. – LnxSlck Oct 22 '16 at 11:44
  • I agree with @LnxSlck – ubugnu Oct 22 '16 at 11:48

Edit the /etc/cups/cupsd.conf file, find the section "loglevel" change "info" to "debug" save and exit then restart cups

# /etc/init.d/cups restart

or for Ubuntu

$ sudo /etc/init.d/cupsys restart

then enter this command to view the log

tail -f /var/log/cups/error_log

With the CUPS LogLevel set to debug, the CUPS error_log will show all programs that are executed during the print job.

Generally there are two data paths taken during a print job;

1) HPIJS driver path

2) Postscript driver path. Both data paths will use the "hp" backend.

For the HPIJS path, look for errors near the ghostscript command (gs) command. The gs command will invoke the HPIJS driver.

For the Postscript path, there will be no gs command. Postscript will be passed directly to the "hp" backend and then to the printer.

Reference

If that doesn't work stop by our great Wiki page DebuggingPrintingProblems

  • I got the following error: [Client 147] HTTP_STATE_WAITING Closing for error 32 (Broken pipe) – ubugnu Oct 22 '16 at 12:22
  • Can you try and install/reinstall qpdf – LnxSlck Oct 22 '16 at 14:01
  • I got the same error – ubugnu Oct 22 '16 at 19:38
  • I tried the following workaround fount in DebuggingPrintingProblems: lpadmin -p <printer> -o pdftops-renderer-default=pdftops . At least now my 20 copies of the same page started printing, but with a delay between each pair of pages – ubugnu Oct 22 '16 at 19:49
  • It seems that pdftocairo work even better – ubugnu Oct 22 '16 at 20:19

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.