1

We have Debian Squeeze 32-bit servers that print PDFs to Xerox DocuColor printers. The PDFs are processed in about six seconds.

We are in the process of upgrading our servers to Wheezy 64-bit. We can print documents, but the same documents take about 36 seconds to print. This is bad, because we print hundreds of documents at a time.

We've looked over the documentation for CUPS, experimented with the fitplot settings (anabling/disabling), updated to the latest PPDs, and changed the default pdftops renderer from gs to pdftops but have not been able to fix this.

We're at a loss as to how to diagnose and fix this.

Any help would be appreciated.

ewwhite
  • 194,921
  • 91
  • 434
  • 799
Rob
  • 234
  • 1
  • 3
  • 9
  • 1
    Likely a [ghostscript issue...](http://serverfault.com/questions/381013/shell-command-slow-when-using-pipe-fast-with-intermediate-file/381048#381048) - Would you be able to run this from the command line (`lp -d printer name file.pdf`) and possibly pull an `strace` of the process? – ewwhite Jul 09 '14 at 13:08
  • The lp command runs quickly. It's the daemon that processes the file that takes so long. How do I strace that? – Rob Jul 09 '14 at 13:17
  • Note that looking at the process list, the slowdown does appear to be ghostscript processing the file. Any suggestions on how to improve this? – Rob Jul 09 '14 at 13:27
  • This seems to be an issue with "pdf2ps". I've tried setting the default renderer to "pdftops" which is faster, but printing seems to ignore the setting. – Rob Jul 09 '14 at 13:39
  • So now you can do this with a raw file. Run `pdf2ps` with a representative file... – ewwhite Jul 09 '14 at 13:40
  • I've compared pdf2ps and pdftops, and the former is what is so slow. So how can I tell cups to use the latter? – Rob Jul 09 '14 at 13:48
  • See my update below. – ewwhite Jul 09 '14 at 13:57
  • Printing is fast when I first run pdftops on the file and print the resulting ps directly. Will look into that. – Rob Jul 09 '14 at 14:22

1 Answers1

1

So this is probably an issue with the difference in Ghostscript versions between OS revisions.

See this question for some tips and analysis of another environment.

You'll want to break this down into steps. The lp job submission is fine, but you want to understand where the ghostscript process breaks down. I also work with high volume unattended production printing from Linux servers, so sometimes this is a case of optimizing workflow, the source document or in extreme cases, downgrading ghostscript or hand-compiling.

You need to see where this is hanging. strace will tell you that. But you can also see if a pdf2ps or something like that is in place. Please obtain the versions of ghostscript from the old OS and the new.

Community
  • 1
ewwhite
  • 194,921
  • 91
  • 434
  • 799
  • 1
    Look into switching to Poppler (versus Ghostscript) or pre-processing/converting your documents in your print workflow. – ewwhite Jul 09 '14 at 13:54
  • Ok, it looks like it's not working. The printers are rejecting the postscript generated by pdftops, and even after using CUPS with ghostscript to print PDFs, they are taking a long time to print on the printers themselves (up to two minutes, versus a few seconds). – Rob Jul 16 '14 at 15:11
  • Is your application generating PDF files or Postscript? – ewwhite Jul 16 '14 at 15:12
  • The application generates PDFs. – Rob Jul 16 '14 at 15:13
  • Well, the difference is that your OS switched to Ghostscript from Poppler between versions. I'm not sure what the appropriate workaround is. – ewwhite Jul 16 '14 at 15:14
  • I thought that on Squeeze the default was ghostscript. Is there a way to simulate what Squeeze does? – Rob Jul 16 '14 at 15:15
  • I think the bug was introduced in a later version of poppler. I'm using an older version from Squeeze, compiled on Wheezy. It seems to work properly. – Rob Jul 17 '14 at 10:31