Chapter 1. Impressario Architecture

This chapter discusses the Impressario printing and scanning architectures and defines Impressario compliance for printer driver and scanner driver developers. By complying with Impressario guidelines, you make your job easier, you ensure a consistent end-user experience, and you greatly improve the chances of effortless transitions to future releases of Impressario.

The following topics are discussed in this chapter:


Impressario allows files of different types to be printed on any installed printer and images to be scanned from a scanner, a workstation monitor, or a Silicon Graphics Image file. A visual end-user environment makes it easy for users to add new devices and for applications to take advantage of those devices by providing graphical interfaces for these purposes:

  • installing printers (see the printers(1M) reference page)

  • modifying printer settings (see PrintPanel [glp(1)] or printers)

  • checking printer status (see PrintStatus(1))

  • submitting print jobs from applications (see the PrintBox widget)

  • installing scanners (see scanners(1M))

  • using scanners (see gscan(1))

To maintain a consistent, reliable, and easy-to-use environment, Impressario provides the following libraries for application developers:


a C application program interface (API) to the UNIX printer spooling system


a C graphical user interface (GUI) library for printing that is compatible with Motif


a C-language API to the Printer Object Database (POD)


a C-language API to the Impressario scanning system


a C-language API for reading and writing Stream TIFF (STIFF) files


a C-language API for reading and writing Silicon Graphics Image files

The following final, crucial elements must be provided by driver developers:

  • For printers: a compliant printer driver that reports printer status through libpod and, optionally, a graphical options panel

  • For scanners: a scanner driver for the driver side of the generic scanner interface and, optionally, a scanner-specific options panel

Impressario Printing Architecture

This section describes the steps that developers of printer drivers and printing applications must take to comply with Impressario specifications.

Figure 1-1 is an overview of Impressario printing components. A more detailed version of this diagram is available online in /usr/impressario/doc.

Figure 1-1. Impressario Printing Architecture

Figure 1-1 Impressario Printing Architecture

The following sections detail the steps that should be followed to achieve Impressario compliance for printer drivers and printing applications.

Compliance for Printer-Driver Developers

The steps shown in Figure 1-2 (discussed below) show how to develop and integrate a printer driver for Impressario.

Figure 1-2. Printer Driver Development Flowchart

Figure 1-2 Printer Driver Development Flowchart

Step 1: Develop Printer Driver (Required)

Your printer driver must comply with the Impressario Filter/Driver Specification (see “The Filter/Driver Specification and psrip” in Chapter 2) so that a model file that is Impressario-compliant can execute the driver correctly. This specification describes standard driver behavior and the command-line arguments that must be processed. See /usr/impressario/src/drivers and Chapter 2 for the source code and an example driver. The driver must update the POD files through calls to “local” functions of the library libpod. (See Chapter 5, “Printing Libraries.”) The formats of the POD files are described in Appendix C, “Printer Object Database (POD) File Formats.”

Step 2: Provide POD Files (Required)

A set of POD files consists of a configuration file, a printer log file, and a printer status file. Each POD file has the same base name as the printer model file. The extensions on these files are: .config, .log, and .status, respectively. To create these files, start with the example set of POD files in the directory /usr/impressario/src/data. The POD files you create must be installed in the directory /usr/lib/print/data when you install your software. See Chapter 10, “Packaging Your Impressario Product,” for more information.

Step 3: Create Model File (Required)

Your model file must conform to the Impressario model file specification. This is done by starting with the template model file provided with Impressario and adding your developer-specific processing. Model files must be installed in /var/spool/lp/model. Follow the Impressario model file template to create a model file that properly updates the desktop printer status icon and interacts properly with Impressario subsystems. (See Chapter 3, “Printer Model Files,” for more information on model files.)

Step 4: Provide Data Filters (As Needed)

Filters must conform to the filter/driver specification. (See “The Filter/Driver Specification and psrip” in Chapter 2 for more information.) Filter programs must be installed in /usr/lib/print. It is recommended that any data filtering be performed directly by the driver. (Filters are programs that change the format of a data file; drivers communicate bidirectionally with the printer.) See Chapter 11 for step-by-step instructions on adding new file conversion filters.

Step 5: Create Graphical Options Panel (Recommended)

This step is optional, but it is strongly recommended that you showcase the features of your printer by providing a graphical options panel program. (See Chapter 4, “Printer Graphical Options Panel,” for details.)

Step 6: Package Software for Distribution (Required)

Package your Impressario software product for distribution. See Chapter 10 for detailed information.

Step 7: Verify Product on Server (Required)

Check that your product media will install the printer support files you have developed on an Impressario server. Run the Impressario test programs testipr and testiconfig to assist in verifying the installation. (See Chapter 9 for detailed information.)

Printing Application Programming Interfaces

To print a document on UNIX systems, you must submit a print job to one of the available spooling systems: the BSD spooling system (lpr command) or the System V spooling system (lp command). The System V spooling system is the default spooling system on all Silicon Graphics workstations. Figure 1-3 shows the general Impressario spooling architecture for the lp spooler. Note that only one of the two paths shown below (PostScript printer or raster printer) would apply. That is, the output is either to a PostScript printer or a raster printer, not both.

Figure 1-3. General Filter/Driver Architecture

Figure 1-3 General Filter/Driver Architecture

Before Impressario, a true application program interface to the BSD and System V spooling systems was not available. Programmers had to create their own application programming interface or execute the lp or lpr command from their application.

Impressario provides the application program interfaces listed in Table 1-1 below.

Table 1-1. Printing Application Programming Interfaces


Interfaces to



System V, BSD

Allows submission of a file or buffer to a printer


System V only

Provides Motif PrintBox widget for printing from application


System V, BSD

Gets status information on the printers currently available

libspool API

In its simplest form, libspool allows you to submit a file or buffer to a printer. It also gives you control of spooling system options and printer-specific options.

libprintui API

The API libprintui is built on top of libspool. The libprintui library contains a widget, compatible with Motif, that you can incorporate directly into your application. If your Motif application needs printing capabilities, libprintui will provide you with all of the basic functionality for submitting a print job as well as access to setting and saving printer-specific options. As mentioned earlier, libprintui interfaces only with the System V spooling system.

libpod API

The libpod library is built on top of libspool and an ancillary system daemon, podd. The libpod library allows you to obtain detailed information about the capabilities of the printers currently available on the system. You can also get detailed status information about the printers. Most applications do not need to use libpod; however, for those that do, libpod provides a very powerful, network-transparent interface.

Figure 1-4 shows the relationship between an application program, the Impressario APIs, and the System V spooling system.

Figure 1-4. System V Spooling System Interface

Figure 1-4 System V Spooling System Interface

Figure 1-5 shows the relationship between an application program, the Impressario libspool API, and the BSD spooling system.

Figure 1-5. BSD Spooling System Interface

Figure 1-5 BSD Spooling System Interface

glp (PrintPanel)

The “print” subsystem available with the IRIX operating system contains the program glp, a graphical standalone print job submittal tool. While not a true API, glp can be used by your application to submit print jobs. It is a standalone wrapper around the PrintBox Motif widget in libprintui.

Printing Application Development

The following Impressario application printing solutions are available:

  • Perform non-graphical print functions via libspool.

    Use libspool, the spooling system abstraction library, for all non-graphical interaction with the BSD or System V spooling system. The libspool library functions perform a large amount of work to ensure successful spooling system interaction, work that a developer may not wish to reproduce.

  • Perform graphical print functions via libprintui.

    Use the PrintBox Motif widget provided by the libprintui library for graphical print job submittal. The widget provides a consistent job submission dialog across all applications and greatly reduces the amount of development effort required. If you use this library, you don't need to use libspool directly. libprintui encapsulates those calls.

  • Obtain printer status via libpod (optional).

    Use libpod library calls to get printer status, configuration, and log information. Status queries must be made through libpod calls; attempts to obtain this information through other means have unpredictable results. In most cases, application developers should use the “standard” forms of the libpod functions (the “local” forms of the functions are for use by printer driver developers and are not network-transparent).

  • Submit graphical print jobs via glp.

    If you are not using Motif, you may use glp to submit graphical print jobs from your application. If you use this method, you should have the print software package (shipped with IRIX 5.2 and later) as a prerequisite. While this method works, it is not recommended, as it is likely to be less efficient than using libprintui.

Complying With the Impressario Scanning Architecture

This section describes how to comply with the Impressario specifications for scanner driver developers and scanner application developers.

Figure 1-6 illustrates the run-time components of the Impressario scanner architecture. Note that scanner applications, scanner-specific options programs, and scanner drivers all link with libscan.a, which has separate modules for scanner applications and for scanner drivers.

Figure 1-6. Scanner Run-Time Components

Figure 1-6 Scanner Run-Time Components

The main and scanner-specific modules of a scanner driver both register callback functions with libscan.

Figure 1-7 shows the interprocess communication of the Impressario scanner architecture.

Figure 1-7. Interprocess Scanner Communication

Figure 1-7 Interprocess Scanner Communication

The following sections describe how to achieve Impressario compliance for scanner drivers and applications.

Developing a Scanner Driver

Follow these steps to develop and integrate a scanner driver that complies with Impressario:

  1. Develop the scanner driver. See Chapter 6, “Scanner Drivers,” and Chapter 7, “Scanner-Specific Options,” for detailed instructions.

  2. Create a graphical options panel. This step is optional, but it is recommended that you showcase the features of your scanner through this mechanism. See Chapter 7, “Scanner-Specific Options,” for detailed instructions.

  3. Create distribution media that will install the driver on an Impressario server. Be sure to check that the media will install the scanner support files you have developed on an Impressario server. See Chapter 10 for detailed information.

Developing a Scanner Application

There are two ways for an application to interact with the scanning system:

  1. Through libscan. This scanning system abstraction library provides a C-language API for scanners. Application programs can use libscan to retrieve data from any scanning device for which a driver exists. See the libscan(3) reference page for a detailed list of the libscan library functions.

  2. As a plug-in module using gscan, which provides a complete graphical scanning interface. When passed the -p option, gscan writes scanned data to its standard output as a Stream TIFF file. After launching gscan with the -p option, applications can use the STIFF routines in libstiff to acquire the scanned data from the standard output of gscan.