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.

8
  • 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, 2014 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, 2014 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, 2014 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, 2014 at 13:39
  • So now you can do this with a raw file. Run pdf2ps with a representative file...
    – ewwhite
    Jul 9, 2014 at 13:40

1 Answer 1

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.

7
  • 1
    Look into switching to Poppler (versus Ghostscript) or pre-processing/converting your documents in your print workflow.
    – ewwhite
    Jul 9, 2014 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, 2014 at 15:11
  • Is your application generating PDF files or Postscript?
    – ewwhite
    Jul 16, 2014 at 15:12
  • The application generates PDFs.
    – Rob
    Jul 16, 2014 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, 2014 at 15:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .