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.

  • 1
    Likely a ghostscript issue... - 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 9 '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 9 '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 9 '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 9 '14 at 13:39
  • So now you can do this with a raw file. Run pdf2ps with a representative file... – ewwhite Jul 9 '14 at 13:40
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.

  • 1
    Look into switching to Poppler (versus Ghostscript) or pre-processing/converting your documents in your print workflow. – ewwhite Jul 9 '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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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