Why should data sent to printers be compressed?
Computers describe print jobs to printers using Page description language (PDL). Some examples you are probably familiar with of such PDLs are XPS, PostScript and PCL. While these languages do a great job accurately describing the document that should be printed, the produced files are fairly large.
Some printer manufacturers have identified this and introduced support for compressed PDL transfer. These printers are capable of receiving a compressed data stream over the network and uncompress it locally before printing.
If you own a printer that is capable of receiving compressed data, you can configure PaperCut to apply compression of print jobs prior to sending them to the printer.
What bandwidth saving should I expect?
This heavily depends on the type and content of print jobs being generated in your organization.
Our internal testing performed on 1,800 sample PCL5, PCL6 and PS spool files showed about 60% reduction of average print job related network traffic.
What’s the downside?
There’s no such thing as a free lunch, and that is the case here as well. Enabling spool file compression means that the print-server spends extra CPU resources to compress the job, and the printer’s CPU works a bit harder to decompress it. The processing latency is likely close-to-negligible, but it is there.
What usage scenarios would benefit the most from print queue data compression?
Slow network connections between the print-server and printer will get the highest benefit from print queue data compression. For example:
- Multiple printers located at remote office, all connected to a centrally hosted server through a WAN connection.
- Print servers hosted on a cloud infrastructure
Fast local networks with a lot of trafficwill also see a benefit in enabling print queue data compression.. This can help to delay expensive infrastructure upgrades as network traffic increases.
Which printers support this feature?
Print-queue data compression is currently offered on some printer models manufactured by RICOH and by Kyocera.
What should I consider before enabling spool compression?
Even printers that are capable of receiving compressed data can have this option disabled in the printer’s admin UI. If compressed communication is attempted with a printer that cannot uncompress it (either because it doesn’t have this capability, or because this capability is disabled in the printer’s configuration) the printer will stop printing, or might even produce endless amounts of pages with garbled text.
Network administrators should be particularly aware that printers might ship from the manufacturer with this option disabled by default. Extra care should be taken when swapping a printer that is connected to a queue with compression enabled:
- Does the new printer support this?
- Is this option enabled in the new printer’s configuration page?
Enabling print queue traffic compression
To enable compression on one or more PaperCut print queues perform the following steps:
- On the print server which holds the print queue, use a text editor to open
- Find the line beginning with
GzipCompress= and add all the queue names that you would like to enable traffic compression on.
Separate multiple queue names with a comma.
Wildcards may also be used.
- Save your changes
- On Windows machines, a restart of the PaperCut print provider is needed
GzipCompress=RICOH LVL1, LIBRARY LVL1
This will enable compression on queues RICOH LVL1 and LIBRARY LVL1.
This will enable compression on all queues that begin with the phrase “Copy Room”
PaperCut is proud to support print queue traffic compression, a new technology that offers great benefits to sites with slow and/or busy networks.
Do you see the benefit of compressing print jobs before transmission, but your printers do not support such functionality? Let us know in the comments section.
Categories: Implementation, Printers
Keywords: optimization, network, traffic, compression