A few customers have asked “how does PaperCut track printing”? This knowledge base article gives a quick overview of the process and explains what’s happening behind the scenes.
- A user at a workstation selects Print… from their application. The application renders the job and it gets sent to the server’s queue.
- The print job arrives in the print queue and begins spooling.
- PaperCut detects the event using standard Operating System APIs (Windows, Novell or CUPS on Mac and Linux).
- PaperCut pauses the job (to prevent printing until analysis is complete).
- Analysis is conducted by reading the spool file. On Windows these are always located on the server in:
- The process that conducts the analysis (the Print Provider) calls across to the Application Server (the central “brains”).
- The Application Server makes a decision if the job should proceed. It factors in details such as:
- The effects of printer filters such as maximum job size
- The balance in the user’s account
- Other access rules
- The Print Provider will either unpause the job (allow it to print) or delete if from the queue accordingly.
As a general rule on all platforms, PaperCut works by interfacing with the Operating System’s standard print queueing system rather than attempting to replace it. This approach means that you don’t loose any of the functionality provided by the underlying OS and in most cases can benefit from your existing setup and queues (e.g. AD driver deployment, existing permissions, etc.)
PaperCut does include optional client software, however this is not involved in the print analysis process. The client software is optional and at the simplest level can be thought of as a viewing tool. It simply acts on the direction of the server to say show the user their account balance, ask them to select an account or confirm a print, or show messages such as low balance warnings. The client software is required to use some advanced features such as popup account selection.
PaperCut is designed according to the Service Oriented Architecture (SOA) principle and has full support for a multi-server and multi-operating system environments. In a standard setup, one server is nominated as the “Primary PaperCut Server” and this hosts the main Application Server. Other servers are called Secondary Servers. Secondary servers run a lightweight monitoring component and communicate with the primary server via XML Web Services over HTTP. PaperCut is a fully cross-platform print management software solution. It is possible to mix server operating systems (Windows, Linux, Mac and Novell) and have them all working together as one.
PaperCut may be hosted in a clustered environment.
PaperCut offers two solutions,
These servers act as an extension of the Application servers’ print provider, they carry out the instructions of the application server, analysing and controlling print jobs.
These servers have 3 simple failure modes should the network between them and the Application server be severed. Read more on these modes in the manual.
To add enhanced resiliency to the PaperCut system Sites servers run a copy of the Application servers database which is replicated constantly to minimise the impact on the network.
These servers can be standalone or print servers on the site, and allow the majority of the application server functions to be carried out (including hold release and MFD Embedded functions used in PaperCut MF), while the site is cut off from the Application server. Read more about site servers in the manual.
- No modification is made to the job at all (unless watermarking, or print attribute modification such as forcing grayscale or duplex, is enabled).
- All queue integration is done via standard APIs and/or reading standard spool files.
- No special driver or driver interaction occurs.
- All analysis is server-side and no client-side printing interaction occurs.
There is some more discussion on the architecture here in the manual:
Keywords: design, function, internals, workings, technical details, system architecture