Speed up Mobility Print Rendering

“Help! I’m a Systems Administrator of PaperCut, and my users are complaining that it takes too long for Mobility Print to print out a document! How can I speed this up?!”

As Mobility Print is increasingly becoming a lot of environment’s defacto print job method due its ease of use, it’s not unreasonable to want it to work quicker than it’s default configuration. To solve this problem we need to look at the key factors that affect this;

1. The source document (things like images, text, font, number of pages)
2. The target printer driver (specially whether the driver is PostScript or not)
3. The performance of the server that is rendering the document (CPU, RAM, overall peak load of printing)
4. The DPI at which we are rendering the document.

As an example here are some rendering times of a 35 page document which has images and some Japanese text;

Rendering times when the DPI is set to 600

Rendering times when the DPI is set to Auto

PostScript vs. Non PostScript drivers

The difference between PostScript and PCL6 rendering times is due to how we handover the interpreted PDF data to the driver. For PostScript drivers, we do a pass through and don’t alter the information we pass to the driver. For PCL6 or non PS drivers on Windows we use the GDI calls to hand over the interpreted data to the driver.

DPI 600 vs. Auto

Our default setting is to use the maximum capable DPI of the printer to render the PDF, this is independent of the printer’s printing resolution which we don’t touch. But applications like AdobePDF Reader or XPdf Reader use their own heuristics to determine the rendering DPI depending on the contents of the file and the printer’s capability. We use XpdfPrint.dll behind the scene to render the PDF. So we can rely on Xpdf to calculate the best suited DPI.

What’s the downside?

By opting for an Auto option when deciding the DPI there may be instances where the detail and quality of a print job may be lower than expected with the originally intended DPI. We also haven’t tested this change with every conceivable printer driver out there, so there is a small amount of risk that this change may not work with your driver in your environment. Give your printers a test and see if there are any issues and if there are, log a ticket with the PaperCut Support Team.

Okay, okay, okay, this all sounds great and everything but what do I need to do?

We’re going to create a user level config file for pc-spool-job. Helpfully this file will persists across any upgrades that will be applied to Mobility Print:

This will force pc-spool-job to discard the given DPI and let Xpdf decide the rendering DPI.

Still have questions?

Let us know! We love chatting about what’s going on under the hood. Feel free to leave a comment below or visit our Support Portal for further assistance.