|
|
|
|
|
|
| HDT47x2
Project Page | HDT47x2
Info Page
THE BASICS OF PRINTER DRIVER DEVELOPMENT FOR WINDOWS (printer driver for IBM 4722 financial passbook printer and printers compatible with 4722)
Introduction Many owners of older printer models (like IBM 47x2), especially bigger companies, go through a painful process when they perform a system upgrade to a Windows platform from older platforms like DOS. A lot of older models are simply not supported and Windows drivers do not exist for them. In some cases it is more feasible to invest in development of drivers instead of replacing the old equipment. This document outlines the basic concepts of printer driver development, that were also applied during the development of the printer driver for the IBM 4722 printer.
Description of the printing process of
a document in Windows. This section illustrates the major relationships between the spooler components during the printing process by walking through the sequence of calls between components during the spooling of a raw format spool file and subsequent playback (despooling) of the file to a bi-directional printer. The following illustration shows the sequence of calls that start with an application initiating a print request by calling GDI (labeled step 1 in the illustration) and end with the local print provider writing a spool file to the disk (step 8) and starting a background thread that will eventually initiate the despooling process (step 9). The sequence of steps in the despooling process is shown in a separate illustration.
Each of the following paragraphs describes one of the calls in the spooling process. 1. The application creates a DC and draws an object to the DC, for example a circle, and then calls GDI with a print request to a particular printer using that DC. 2. GDI calls the printer driver with a request for instructions on how to render the circle on that particular printer. 3. The printer driver returns the instructions on how to render the circle on the printer the driver is associated with. Note that all Windows 95 printer drivers are 16-bit code and communicate with 16-bit GDI. 4. GDI passes the print request to 32-bit GDI because the Windows spooler process is 32-bit code. 5. GDI32 makes an interprocess call to the spooler process. 6. SPOOL32.EXE calls the router to route the print job to the printer specified by the application. In this example, the router sends the print job to the local print provider. Note that the router could send the job to a printer on the network through the network print provider (which is not shown in the illustration). The default Windows 95 spooler spools the network jobs locally, so they show up on the local spooler queue, even those jobs bound for Windows NT servers. A network print job is spooled and despooled on the client machine, not the server. It is only in the relatively late step of despooling that the remote print server is actually contacted. The way Windows 95 handles network print jobs contrasts with the way they are handled by Windows NT client machines, which use RPC to call the necessary printing APIs on the print server. This way, the print job never shows up on the local spooler queue and the spooling and despooling is handled by the print spooler on the print server. On Windows 95 RPC is not used by the default print spooler. A print spooler that does use RPC is available as an option for Windows 95 client machines. 7. The router calls the local print provider with the print job. 8. If the the type of the print job is not direct, the local print provider spools the print job to the disk as a raw-format spool file. Note that steps 1 through 8 can be repeated many times to build a complete spool file. In step 8, the local print provider appends each piece of the print job to the spool file until the application signals that the job is complete by issuing an EndDoc function. The difference between a direct print job and a spooled print job to the local print provider is apparent in the next illustration, which shows the playback of this spooled file. When the local print provider is called by the print processor (through the router) with this same print job, the job type is direct instead of spooled. That results in the job going to the printer instead of being rewritten as another spool file. 9. The local print provider starts a background thread that will determine the best time to start playing back the spool file to the printer. The next illustration shows the sequence of steps involved in playing back the raw spool file. The following illustration shows the sequence of calls that start with the background thread application initiating the playback of a spooled file by calling a print processor (labeled step 10 in the illustration) and end with the local port monitor sending the print job through a port it controls to a connected printer (step 17).
Each of the following paragraphs describes each of the calls in the despooling process. 10. The main thread determines a good time to initiate the playback of a spooled file, based on the changing state of spooler subsystem resources monitors. When it is a good time, the main thread uses a StartDoc function call to start a new thread in the print processor to playback the spooled file. 11. Because it is a StartDoc case, the print processor thread invokes the local print provider with a ReadPrinter function call to read part of the spool file off the disk. (Note that in this example case of a raw spool file, the print processor does not call GDI32. In the EMF spool file case, which are played back by the default print processor supplied by Microsoft, the print processor calls GDI32 to playback the metafile.) 12. Because it is a StartDoc case, the print processor thread invokes the language monitor (through the local print provider) with a WritePrinter function call to send the data through the physical port connected with the bi-directional printer originally specified in step 1 of this whole process. For a raw spool file, the default print processor simply passes the data through, without changing or interpreting any of the information. Note that a language monitor is invoked in this example scenario because the destination printer is a bi-directional printer. For non bi-directional printers, a port monitor would be invoked instead of a language monitor. Note also that although this example scenario shows the language monitor and port monitor as separate components, they can be integrated into one monitor. 13. The language monitor calls the port monitor to send the data to the printer. 14. The port monitor sends the raw data through the physical port to the connected printer. Note that steps 11 through 14 are repeated until the end-of-file is reached on the spool file (or the print job is canceled). Then the playback thread is terminated.
Description of the components of the Windows NT printer driver Picture 1 shows the place of the printer driver in the printing architecture of Windows NT.
Only through GDI, the Win NT printer driver communicates with the application and by using the spooler it sends instructions for printing to the printer. That means that the printer driver is commanded by requests from the GDI. If the driver notices that the request for printing can be processes by the GDI services. It can reroute the request to the graphics engine. Printer Driver The Windows NT printer driver consists of the following components: · The Graphics Driver DLL implements the DDI to a level needed to support the printer rendering and the requirements that can not be processed adequately by the graphics engine. · The Interface Driver DLL creates an interface which enables the users to configure the physical characteristics of the printer and the logical characteristics of the document. This interface is also responsible for the interaction with the "Common Property Sheet User Interface" for showing the configuration window(s) after a request by an application. · The Printer Device data file fetches specific information about the printer to the printer Graphics and Interface Drivers. The type and the content of the file depend on the printer model. A printer driver can be used for specific printer or a family of printers. Three types of printer drivers are included with Windows NT and they are: the "Raster Device Driver" (RasDD), the PostScript driver and the plotter driver. The components that these drivers consist of are on the following table:
For example, the three components that build the "HP IIIsi PostScript" driver are:
These three types of drivers support most of the printer models available on the market today. A driver is needed for a certain printer only if that printer is not compatible with any of the above mentioned drivers.
The IBM 47x2 printer fits in the group of "Raster Devices". That means that its engine is based on the DLLs of RasDD driver type. In order to develop a driver for this printer model, only a "Raster Minidriver DLL" has to be developed first. Picture 2 shows the system components necessary for printing "Raster Device" in Windows NT:
This picture shows the components that are part of the "raster device driver":
If a driver is to be developed for a new printer model, it is only needed to develop a new minidriver or modify an existing one.
Printer Driver Components Description for each one of the driver components follows: Graphics Driver (Raster Device Driver - RasDD) RasDD is included with Microsoft Windows NT for the purpose of easier raster printer driver implementation. RasDD can process different kinds of requests in connection with the printing, like for example: text printing, bitmap rendering and page advancing for different printer models, which means that the driver developer does not need to rewrite that code again. Instead of that, only a minidriver for that printer model should be developed. RasDD uses the minidriver in order to obtain information about the printer. For example, RasDD receives the needed information from the minidriver in order to determine the actual resolution of the printer, to determine the fonts supported by the printer, etc. Printer Driver Interface Through the Win32 Printer Folder in Windows NT, the user has access to the parameters for the printer like for example: the name of the printer, the port to which the printer is connected, the resolution used, the page size, etc. For this purpose, the printer drivers must have interface DLL that holds all the functions for handling the attributes of the printer and the document from the side of the users. This component and the Graphical Driver are needed for rendering of the picture that will be printed. Minidriver The minidriver is in fact a GPC (Generic Printer Characterization) file used by RasDD for printing on raster printer device. It includes a collection of data called printer data tables. These tables have data for the resolution, colors, font metrics, and strings for different printer commands. Also, this file specifies how the corresponding printer processes the primitive bitmaps and text.
Implemented modules:
Additional:
|
|
|
About - Business - Experience
- Projects Copyright © 2001 Halkyon Development Team Ltd. |
