Chapter 1. Impressario Architecture
Prev |  | Next

## 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 Printing Architecture”

- “Compliance for Printer-Driver Developers”

- “Printing Application Programming Interfaces”

- “Printing Application Development”

- “Complying With the Impressario Scanning Architecture”

- “Developing a Scanner Driver”

- “Developing a Scanner Application”

## Overview

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:

`libspool` |  | a C application program interface (API) to the UNIX printer spooling system
`libprintui``` |  | ``a C graphical user interface (GUI) library for printing that is compatible with Motif
`libpod` |  | ``a C-language API to the Printer Object Database (POD)
`libscan``` |  | ``a C-language API to the Impressario scanning system
`libstiff` |  | a C-language API for reading and writing Stream TIFF (STIFF) files
`libimp` |  | 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

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

#### 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

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

API | Interfaces to | Function
--- | --- | ---
libspool | System V, BSD | Allows submission of a file or buffer to a printer
libprintui | System V only | Provides Motif PrintBox widget for printing from application
libpod | 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-5 shows the relationship between an application program, the Impressario `libspool` API, and the BSD spooling system.

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

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

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.

Prev | Table of Contents | Next
About This Guide |  | Chapter 2. Printer Drivers