The Technical Committee of the Salutation Consortium is considering changes to the Salutation Architecture in preparation for releasing version 2.1 Two changes are enhancements to the DocStore and Print Functional Units.
DocStore Enhancements
Part 2 of the Salutation Architecture Specification defines the DocStore Functional Unit as "a temporary spooling storage for document data handled at scanning, printing and Faxing operation. It provides a client with simple access methods to temporary spooling storage, and defines minimum functions for the purpose. DOC Storage Functional Unit abstracts a container of documents as folder, and may contain more than one folders. Implementation of DOC Storage Functional Unit can be typically found in a facsimile machine, copier, printing equipment, and so on."
Close examination of this architected container structure shows it is applicable to other spooling store applications. For example, the DocStore Functional Unit can be used to contain the device driver code for a Salutation-enabled device. Using a Salutation Service Session, this device driver may be accessed by a client wishing to utilize the Functional Units contained in the device. For example, a Client Functional Unit may locate a Print Functional Unit using the Salutation discovery protocol. Should the Client Functional Unit wish to use the Print Functional Unit, but not have access to a device driver for that product, the Client Functional Unit may discover, then access the contents of a DocStore Functional Unit containing the Print Functional Unit's device driver. Using the Salutation Personality, the Client Functional Unit may retrieve the device driver, install it locally and print effectively on the Print Functional Unit.
It may be argued that a new Functional Unit should be architected for the function of containing non-document data. However, this would require the support of an additional Functional Unit thus increasing the Salutation footprint for the implementing device.
Print Enhancements for Win32 Raw Data
Under Windows, it is possible to create a single drawing function that accepts a device context as a parameter. That drawing function generates graphics commands in the form of Graphic Drawing Instructions (GDI) which will draw on either the screen or the printer depending upon the device context selected. A printer device context is used in exactly the same way a device context for a display. This means that all graphics functions work the same way for printers as they do for display devices. This provides application/device independence for the 32-bit Windows operating system.
In the case of Win32 printing, when an application performs graphic operations on a printer device context, these graphic operations are recorded in the form of journal records. The process of collecting journal records is similar to the metafile process which records graphic operations for played back as needed.
After a page has been completed, the journal records are run through a print processor. The print process is a driver that converts the journal records into lower level Device Driver Interface (DDI) calls that are supported by selected printer's device driver.
Next, the graphic engine for the selected printer converts the print processor instructions into the raw binary data that is required for the selected printer. This is the Win32 Raw Print Data Stream.
The spooler then sends this Win32 Raw Print Data Stream to the printer that has been selected via the device context. This is accomplished through calls to a DLL called a port monitor. Typically, in a Windows environment, a printer is attached to a serial (COM) or parallel (LPT) port which are standard on most desktop and laptop computers. The port monitor is responsible for making a physical connection between the printer spool staging the Win32 Raw Print Data Stream and the port to which a printer is connected.
One "port" that can be assigned to a printer is "File".
Printing to this port generates a file on a disk. This file holds the Win32 Raw Print Data Stream generated by the graphics engine for future use.
The Salutation Consortium Technical Committee is considering specifying an emulated mode for Win32 Raw Print Data. This provides for the discovery of services which support this type of data stream. A Salutation client may then generate Win32 Raw Print Data, and, using Salutation protocol, send the data to the Salutation server for printing.