Figure 14.1 shows the path taken by printer data from the print processor to a printer that a) has a language monitor associated with it; and b) does not have a language monitor associated with it.
Figure 14.1 Printing data flow (a) without a language monitor; (b) with a language monitor.
When a language monitor is associated with a printer driver during the driver’s installation, all print data that flows from the printer driver to the printer goes through the language monitor before being passed to the port monitor. That is, all calls that the spooler makes to print a job go through a language monitor if one is associated with the printer.
A language monitor should then make the appropriate calls to the port monitor with which it is working. For example, a language monitor’s StartDocPort implementation might call the associated port monitor’s StartDocPort implementation to do generic print job setup and then set up its own language-specific job control information for the first port write.
Note that a language monitor never communicates directly with a printer port; it relies on the port monitor to send and receive printer data for it. Note also that, regardless of printer type, the print data stream should always be handed to the printer’s port by a port monitor.
Language monitor writers should gracefully handle attempts to read from printers and files that cannot be read back from. For example, a language monitor written for a driver class that contains both bidirectional and unidirectional printers should handle ill-fated read attempts on unidirectional printers.
Because language monitors and port monitors are discrete architectural components, it is possible for vendors of bidirectional printers to develop only a language monitor and use an existing port monitor. Or, if vendors also require special port monitor features that will only be used in conjunction with their language monitor, they can develop a combined language monitor and port monitor (LMPM). An LMPM can work with other port monitors.