Advanced Printing Software uses an object-oriented
architecture. Each logical element is implemented as an object.
There are several types of objects in the system:
A server object is a component that describes
services provided and objects supported by the system.
Advanced Printing has a two-tier server architecture. A
spooler accepts, queues and schedules jobs for
printing. A supervisor controls the actual
printers; it sends print data to them and reports status
information. Each named server object is associated with
a server process and a persistent disk based database.
- Logical Printer
A logical printer object is the user's view of a
printer and provides defaults for jobs printed through
it. Logical printer objects reside in a spooler.
A Queue object accepts print jobs from one or more
logical printers and holds them until a suitable
physical printer is available. Queue objects reside in a
- Physical Printer
A physical printer object is a software abstraction
of an actual printer device. It maintains information
specific to a printer device, such as its capabilities,
its address and port, and its status. Physical printer
objects reside in a supervisor.
A Job object is a collection of user supplied
document files and print attributes that direct when,
where, and how the job should be printed.
A Document object is a user supplied file and
attributes that direct how the document should be
printed within the job.
- Initial Value
An Initial Value object contains a set of attributes
to be applied to a print job or document. It provides a
means for attaching the same attributes to each job
submitted to a particular printer. It can also serve as
a convenience to users who want to consistently specify
a predetermined set of attributes with a certain class
of jobs, such as monthly billing or inventory lists.
Figure 1 illustrates how the major objects are
interconnected. Network connections are shown in red.
Clients in the network environment submit requests to
servers. Typical user requests include printing jobs, and
requesting a list of jobs in a queue. Administrators can
issue management requests, such as those to create a print
queue, set up an object's notification profile, or to set up
printer defaults. Print jobs submitted to a logical printer
are stored in a queue, and from there, flow through an
available physical printer object, to a printer device. An
administrator can dynamically change the association between
printer and queue objects using a CLI command or a GUI tool.
The architecture allows for very flexible configurations.
For example, multiple logical printers (submission points)
can feed jobs into one queue and these logical printers can
provide different job defaults. You can set up one logical
printer for two-sided printing and another for one-sided.
Users can submit jobs to one or the other depending on their
Spoolers and supervisors can communicate across hosts. If
your printers are network connected, then you can run the
supervisor on just about any host in your environment. If
you have printers that are physically connected to a host,
you must run a supervisor process on that host. You
generally need only one spooler for all your physical
Print jobs and their associated documents are also
implemented as objects. A job is made up of one or more
documents submitted by the user to print in a single
request. A document consists of print data and printing
All system objects have associated attributes that
describe them, define their behavior, or provide
instructions to the system. For example, the physical
printer object has an attribute, "sides-supported" that
indicates whether the printer is a capable of two-sided
printing. A user would set the "sides" attribute of a
document to 2 to indicate that the document should be
printed on both sides of the paper. There are literally
hundreds of attributes associated with the print system
As you create objects in the system, the servers record
object bindings in a local name file. The name file contains
the name of each object, and a binding to the server that
clients can use to access it. Administrators can publish the
name file as a NIS map or with Lightweight Directory Access
Protocol (LDAP) to make objects visible to clients in the
Advanced Printing Gateways
Advanced Printing Software includes an LPD inbound gateway
client. This gateway accepts jobs submitted via the standard
LPD remote protocol (RFC 1179) and submits them to an
Advanced Printing spooler. It also communicates directly
with the LPD daemon to efficiently transfer local jobs
submitted with the lpr command.
The package also includes an "outbound" LPD gateway
supervisor that can tranfer jobs to remote hosts or printers
that accept LPD print requests. The outbound gateway
supervisor can emit print jobs using distinct extensions to
RFC 1179, including those of Solaris(TM), Digital UNIX,
Xerox DocuPrint NPS and Xerox DocuTech 6135. This capability
allows the system to take advantage of commonly available
LPD extensions that a remote server can provide. Remote
hosts do not need to be running Advanced Printing Software.
Back to Advanced Printing overview
Proceed to Advanced Printing clients