To explain how SavaPage works we first introduce the key concepts for the usage scenarios. After that we will describe a typical work flow, and end with a high-level overview of the application's architecture.
Each concept is described in an abstract definition with its SavaPage implementation.
A print server is a system responsible for hosting print queues and sharing printer resources to client workstations. Client users submit print jobs to a print server rather then directly to the printer itself. A print server may be a dedicated server. However, on many networks this server may also perform other tasks such as file serving.
SavaPage is a regular Print Server in the technical sense, but is special in the sense that it shares multiple print queues of the one SavaPage virtual printer. The GNU/Linux host where SavaPage is deployed on may offer file services on its own account.
A print queue is first-in-first-out queue holding all jobs pending on a given printer.
SavaPage virtual queues redirect print jobs to the originating user's personal queue called SafePages. The SavaPage Web App is the viewport on these SafePages.
In a multi-user environment, users login to a network or computer using a username and password. Often these are managed by services like Active Directory or LDAP. The username is known as the user's identity.
SavaPage uses this identity for authentication and auditing purposes.
Note
User authentication is a topic of its own. Please see Chapter 15, Authenticated Printing for more elaboration on the User concept.
Client software is a small application that runs on each workstation and communicates with a central server. The printing process on most networks works according to a client/server model with clients (workstations) submitting jobs to a server.
SavaPage utilizes the client/server model with standard components on the workstation, i.e. an IPP or JetDirect printing client and a Web browser.
An application server is a server program responsible for centrally processing “business logic” and providing services to end-users.
SavaPage is an application server since it provides “business logic” for showing, editing and routing printed documents.
A provider is a software component or program responsible for providing information to an Application Server.
SavaPage uses an integrated IPP and JetDirect Server to capture Driver Print jobs from client workstations and devices. It communicates with IMAP to capture Mail Print jobs and uses HTTP upload to capture Web Print jobs. The generic information provider for capturing print jobs is called the “Print Provider”. Other important providers are “User Directory Provider”, “Authentication Provider” and “CUPS Information Provider”.
A Web Application, or Web App for short, is a software program that interacts with end-users via a web browser. A Web App gives flexibility because it allows access from any location on the network and avoid the need for installation of separate software.
SavaPage provides a web-based interface for end-users and system administrators. Since it is optimized for desktops and mobile devices an even greater flexibility is achieved.
SafePages is the SavaPage term for the personal user space with accumulated jobs from SavaPage printer queues. See Section 1.3.1.2, “Print Queue”.
Proxy Printer, or ProxyPrinter, is the SavaPage term for a printer that is available in the SavaPage Web App for printing selected SafePages.
Important
It is important to understand that using a Proxy Printer does not require its printer driver on the client workstation. Proxy Printer queues are CUPS queues located on the GNU/Linux SavaPage host and are not shared on the local network, hence not visible for client workstations. Proxy Printer queues can only be selected and used in the SavaPage Web App sandbox for pass-through printing.
To illustrate what SavaPage is about and how it works we'll start with a simple use case.
Note
Advanced user scenario's are described in Appendix A, Proxy Print Scenarios.
-
John opens a web browser, clicks on the SavaPage bookmark and logs into SavaPage with his regular Active Directory credentials.
-
John prints a document from his favourite editor to his SavaPage Network Printer.
-
John sees the printed pages appear as thumbnails in his web browser.
-
John browses through the thumbnails and zooms in on page 15 and 16 to see more detail.
-
Things look good, apart from two void pages at the end. So, John deletes these pages using the Delete dialog.
-
After selecting the company letterhead as standard background, John selects the Brand-X Multi-functional Proxy Printer located down the hall, checks the settings (duplex and grayscale), and presses the Print button.
-
Since John also wants to save a PDF document of the result, he sets the PDF properties (title, author, subject, keywords, encryption) and presses the Download button.
Note
John could also have opened a web browser on his smartphone and do exactly the same things.
This is what happens behind the scenes.
-
When John prints to SavaPage from his editor, his workstation transfers the print job to the SavaPage Print Server.
-
The SavaPage Print Provider handles the print job, analyzes the information and retrieves:
-
The identity of the user who printed the document.
-
The identity of the queue the job was printed to.
-
-
The Print Provider submits the information about the job to the Application Server to process the business logic.
-
The Application Server approves the print request, transfers the job to the user's SafePages, and signals John's browser session that a new job has arrived.
-
The Web Application in John's browser picks up the signal, handles the information and displays the newly printed pages.
-
The Web Application transfers each of John's editing actions (delete, letterhead) to the Application Server where the state of the SafePages is saved.
-
When Johns selects the Brand-X Multi-functional Proxy Printer, the Web App asks the Application Server for the printer options, so it can display the Printer Settings dialog for this specific printer.
-
When Johns presses the Print button, the print action plus the selected printer options are passed to the Application Server. The server composes the print job (applying editing actions and selected letterhead) and sends the result to the Proxy Printer, using the printer options John selected.
-
John's download request is fulfilled by the Application Server with a PDF document holding the edited SafePages, including the letterhead, and the chosen PDF settings.
Figure 1.1, “SavaPage High-Level Architecture” shows a high level view of the components and communication involved.
-
The SavaPage Print Server synchronizes users from the LDAP/NIS source to its own SQL Database.
-
The Client Web Application on desktops, laptops and mobile devices communicates with the Application Server using HTTP.
-
Desktop and laptops users can be forced by their OS to login and be authenticated at the LDAP/NIS source.
-
SavaPage Web App users on desktops, laptops and mobile devices are authenticated by the SavaPage Print Server at the LDAP/NIS source.
-
Desktop and laptop users print to SavaPage with the SavaPage printer driver using IPP or JetDirect protocol.
-
macOS and iOS users can print to SavaPage with AirPrint®.
-
Every user can use SMTP to Mail Print to SavaPage.
-
SavaPage uses IMAP to monitor the Web Print Inbox.
-
Every user can use HTTP to Web Print to SavaPage.
-
The Content Repository holds letterhead documents.
-
A print command in the Web App to a Proxy Printer is executed by SavaPage with an IPP operation to local
CUPS.