The PrintKit software has proven to be a good match to this situation. Because of its configurability, you can add support for new printers without changing the underlying software. Within PrintKit, the definitions that provide support for a particular printer model are encapsulated as a well-defined, self-contained set of modules. So new definitions are localized, and they don't have unexpected side-effects when you add them to your existing configuration.

When you add a new printer, you may want to verify that it works correctly with your applications, but you don't have to revalidate your entire printing configuration. This can make a big difference in support costs, particularly for systems subject to regulatory requirements. In practice, customers may use the same underlying version of PrintKit for many years, while adding new printers on a regular basis.

This document provides a description of how PrintKit's configuration works, and how it localizes changes. It describes what changes when you add a new printer model and what changes when you upgrade the software. It describes the testing process we use to test PrintKit with new printer models, and how you can perform similar testing. Finally, it discusses a strategy for revalidating your printing sevices after an upgrade.

The objective is to allow you to plan for configuration changes and upgrades without surprises -- to have a better understanding of what will change, what can break, and what to test. Adding a new printer is relatively straightforward. A software upgrade, although a significant undertaking, can be made manageable if planned systematically.

All of PrintKit's configuration information is contained in the PrintKit configuration database, and the primary PrintKit device control library.

The configuration database is contained in a file in your system directories:

PRINTKIT_CONFIG.DAT	(version 2.2 and earlier)
PRINTKIT_CONFIG_023.DAT	(version 2.3)

It is normally located in SYS$SYSTEM, but if you have moved your system Queue Manager database to a different location, the PrintKit database will be located in the same directory as QMAN$MASTER.

The primary PrintKit device control library is located in the system library directory:

SYS$LIBRARY:PRINTKIT.TLB	(version 2.2 and earlier)
SYS$LIBRARY:PRINTKIT023.TLB	(version 2.3)

When you do a SHOW MODEL command in the KITCP utility, what you see is a model record from the configuration database. The model record refers to modules in the device control library through its /PPD qualifier. There is always a primary PPD module associated with a model definition, and there may be one or more auxiliary modules. All share the root name specified by the /PPD qualifier, which is unique to each model.

PPD stands for PostScript Printer Description, a specification developed by Adobe Systems. A PPD file describes the characteristics of a particular printer model, and provides PostScript control sequences for controlling its features.

PrintKit uses a small portion of the PPD information. (Much of the PPD specification, such as configuration for GUI-based printing interfaces, is not relevant.) This is what PrintKit gathers from the PPD file (names of the referenced PPD entries are in parentheses):

The PPD files used by PrintKit are those provided by the printer vendors (for Windows or Mac systems, typically), so they are generally well-tested and represent the vendor's best practices. We occasionally need to make adjustments, when the PPD file makes assumptions about its use within a GUI or uses vendor-specific extensions (most frequently with finishing controls).

To validate a new printer model, we exercise the printer with a series of print jobs to ensure that communications and job control are working correctly, and we run a set of simple tests on printer-specific features. Then, we monitor the printer in normal use, watching for anomalous behavior.

You can do the same thing if you are using a printer model that is not yet validated, or if you want to cross-check that a printer is working correctly with PrintKit. You should also test sample output from your key applications.

A basic set of tests takes a few minutes once you are familiar with the procedure.

The easiest way to test communications and job control is to run the PrintKit IVP:

Repeat the IVP a few times to verify that jobs print without errors or unexpected delays. This also tests emulator selection.

Here is a sample set of feature tests. You'll need to adapt it to the feature set of the printer you're testing and your local printing practices.

duplexing

input trays

Use the tray names defined for your printer model. Do a KITCP SHOW MODEL /FULL and examine the /INPUT_TRAY_SUBS qualifier to see which standard tray names are defined; for the full set of tray names, examine the PPD file for the printer (or contact us for help). If a tray contains a paper size other than the queue default (LETTER or A4, typically), you'll need to specify the SHEET_SIZE parameter for the INPUT_TRAY parameter to work correctly.

output trays

Use the tray names defined for your printer model. Do a KITCP SHOW MODEL /FULL and examine the /OUTPUT_TRAY_SUBS qualifier to see which standard tray names are defined; for the full set of tray names, examine the PPD file for the printer (or contact us for help).

media selection

Test the sheet sizes you expect to use with the printer, and any medium definitions you have created for the printer.

finishing

Use the finishing specifications defined for your printer (or contact us for help).

Problems to watch for as you use the printer:

An upgrade to the PrintKit software is much like any other software upgrade, with similar potential for changes and side-effects. Fortunately, print symbionts operate in a constrained environment, with relatively simple, well-defined interfaces to other system components. This greatly limits the scope of interoperability testing.

The PrintKit symbiont, like other symbionts, is controlled by and receives print jobs through the symbiont interface. It does not interact directly with software applications, which submit print jobs through the queue interface. The symbiont in turn calls on system services and, in the case of the PrintKit symbiont, a TCP/IP services layer.

Job submission remains unchanged when you upgrade the PrintKit software – it's handled by common system services, which continue to deliver the same information to the symbiont.

What does change is how the symbiont processes the print job, which is the same functionality that you test when adding a new printer. This means validation after a software upgrade is very much like validating a new printer – except the changes potentially affect your existing PrintKit queues.

Consequently, validation should include the same tests as for a new printer model, applied to at least a representative selection of your PrintKit queues.

It is also very important to test the output from your key applications after an upgrade. The emphasis in testing a new printer is to check areas that are potentially different between printers. Document processing is common across printers, so it's an unlikely source of problems. However, upgrades do affect this common code, and it's always possible your documents have unique features that we missed in testing.

The key preparatory step for testing applications output is to determine what output needs to be verified, and to collect samples or establish procedures for testing.

In summary, validation after an upgrade involves rechecking the correct operation of your PrintKit queues, using the same tests are for new printer models, with added emphasis on testing samples of output from your key applications.

The PRINT command parameters used to select printer features are described in the PrintKit User Manual, Appendix A.

PostScript Printer Description files are described in the PostScript Printer Description File Format Specification, Adobe Systems Incorporated, part number LPS5003, available from the Adobe web site.