0

Writing an app that needs to send a pdf to a laser printer. The PDF has tons of large imags in it. Using cups PS driver takes 8 minutes. Using cups gutenprint driver works perfectly, and takes 50s - but only seems to support grayscale.

So, trying to punch directly to the printer. Used

ippTool -tv -f myfile.pdf ipp://address printfile.ipp

where that file contains ATTR mimeMediaType of application/pdf - and a bunch of other settings like language. It all goes to the printer fine, but we just get pages starting with pdf signature - so it's just reading the document as text.

Any ideas how I can quickly get this document to the printer? Using pcl6 drivers under windows - the document takes 2 minutes to print out. The printer is a Ricoh SP C250DN.

Darren Oakey
  • 2,894
  • 3
  • 29
  • 55

1 Answers1

1

The printer doesn't support direct PDF printing which is why sending the PDF file directly to it doesn't work. In the absence of instructions the printer assumes what its being sent is PCL and PCL is specified so that if you send it text, it just prints it. PDF files look enough like text for that to happen.

So you need to create either a PostScript or PCL representation of your PDF file (because that's what your printer supports). My guess is that CUPS is converting it to PostScript for the best quality output, using Ghostscript to do the work. This will mean that all the image data is decompressed, and then recompressed into PostScript, which is probably where the time goes.

You could instead try using the Ghostscript pxlcolor device which produces PXL output, or you could try one of the many various PCL6 devices to produce PCL output and see if that's faster and if your printer likes it.

You could also try using the ps2write device to produce PostScript and try that. Its possible that your setup is using a sufficiently old version of Ghostscript/CUPS that its using the old pswrite device, which produces huge, slow PostScript that takes an age to send to the printer and a long time to print.

In the above cases just use something like :

gs -sDEVICE=ps2write -o out.ps

and then use ipptool to send the resulting out.ps file to the printer. NB you may need to prepend the file with some PJL to switch the language into PostScript, and postfix it with the correct terminator code.

You can do the same with the PXL/PCL output files, but you shouldn't need the PJL wrapped around it there.

Note that if you are writing an application, you need to be careful using Ghostscript, as its covered under the AGPL. But if you can find a way to make that work acceptably you should be able to configure CUPS to do the same, instead of whatever its currently doing.

KenS
  • 30,202
  • 3
  • 34
  • 51
  • awesome answer... we actually fixed the problem using pdftops - which gave 1/10th the file sizes of gs - I'm guessing because it looks like gs was rasterizing all the fonts - but really appreciate the indepth answer. – Darren Oakey Aug 24 '17 at 05:58
  • Yeah that sounds like you were using pswrite, you really don't want to do that (and in current versions **can't** do that, because we killed the device). You should use the ps2write device, the PostScript is a lot smaller and runs a lot faster. – KenS Aug 24 '17 at 07:19
  • actually - I looked at the commands we were using - and we _were_ using ps2write. I'll dig up the full command line next time I'm in the office. We now just use pstopdf to generate a ps, and then ipptool to pump it straight to the printer. Consistently under 3 minutes now, which is good enough. – Darren Oakey Aug 24 '17 at 08:29
  • Hmm ps2write should not bitmap fonts (unless they started that way of course). I'm also a bit surprised that you would get a 1/10 size PostScript file from another PostScript output. Of course, we had to disable some of the compression in ps2write because crappy PostScript implementations (cheap printers) couldn't handle it. If you're getting much smaller output you may want to watch out for that. – KenS Aug 24 '17 at 11:07