CUPS is a modular, open source printing system for Unix-like operating systems, which allows a computer to act as a print server. It can accept print jobs from client computers, process them, and send them to the appropriate printer. CUPS is included with many Linux distributions, and it currently serves as the basic print facility for the Apple Macintosh platform. It has one job, and it does that job reasonably well. Where it starts to fall apart is when it tries to be all things to all people.
Formerly known as the Common Unix Printing System, CUPS is a fairly basic, straightforward utility that can be customized though the use of filters. At a high level, it consists of two sections: a CUPS server and a CUPS client, which may or may not run on the same device. The CUPS client is essentially the transport mechanism to get jobs and notifications back and forth between the user and the server. The CUPS server handles all of the queuing, printer statuses, and rendering in different PDL’s (Page Description Languages) as well as finishing options. Given enough knowledge of the inner workings of the CUPS server and CUPS client, you can write filters to do a myriad of tasks, including a unique one I created in a past life and shared via video:
https://www.youtube.com/watch?v=WzEhKs_CvJc/
So, when might you use CUPS and when does it make sense to look at an enterprise print solution like the VPSX product? This depends on factors like the size and complexity of your print landscape as well as the ability of your support team to develop and customize scripts. In order to configure CUPS server printing, only the core part of the queues and some queue options can be configured using a web interface. Much of the environment must be hand built or manually configured. This requires a higher level of expertise than an enterprise output management solution like VPSX® software, which provides web-based screens for most administration and customization functions.
CUPS falls short when you have to manage printing from several disparate systems, all with their own little nuances. Solutions such as VPSX software shine in situations like this. Let’s use an example I’ll call “Village by the River”.
There is a village by a river that produces souvenirs that tourists like. There is a larger city across the river that tourists frequent, where villagers sell their goods. It is roughly 10 miles to get there via the paved road around the dam; however, there is also a narrow walking bridge across the river only 1000 feet long but just 4 feet wide. At times it may make more sense to transport the goods by walking over the bridge; for example, when only small numbers of souvenirs need to be delivered from a single shop in the village to someone in the city. However, if a store in the city needs large volumes of goods from multiple producers to replenish their warehouse and wants the deliveries to arrive on a predictable schedule regardless of weather, then the paved road makes more sense. So, the “best” solution really depends on the expected amount of freight and frequency of travel.
There is an old saying: “When all you have is a hammer, everything looks like a nail.” A Linux CUPS server may be an effective hammer in a variety of situations, but eventually there comes a time when a screwdriver really is the best tool for the job. At that point, don’t try to shoehorn in a solution where it doesn’t fit. In the end, you will spend more time trying to keep it running and make it work in scenarios that it wasn’t designed to handle.
Also, please be careful when researching your printing requirements, since the solution you choose will most likely still be around long after you have moved on from your current project or position. On that note, I’ll leave you with a parting thought from one of my favorite project implementation cartoons:
http://projectcartoon.com/.