The Leader in TIFF Imaging Solutions
Tech Note: ImageMAKER Printer Drivers (Overview)
All of our print drivers use a common architecture to provide an interface to an OEM-written user interface.
The Print Capture Driver is designed to easily integrate into any fax application. The driver, no matter what platform it is intended for, is broken into two components: the Print Driver, with whatever ancillary files are required for its operation, which ImageMAKER provides; and the Control Dialog, which is responsible for providing user interface (if any) at print time, and is written by the OEM with reference to samples which we provide. ImageMAKER Print Capture is responsible for capturing print commands to an in-memory bitmap and writing the bitmap to a TIF, BMP, DCX, or PCX image file format. The Control Dialog provides the user interface, linking the addressing, cover page generation, fax preview, and fax send functions to ImageMAKER Print Capture operation. The Control Dialog is implemented as a separate executable, called at start of printing, and it in turn controls the operation of ImageMAKER Print Capture. When printing is complete, ImageMAKER Print Capture reports back to the Control Dialog the status of the print job.
Note that the name "Control Dialog" is a bit of a misnomer, which is retained only for historical reasons. The original purpose of this application was to put up a dialog which could be used by the end user to enter details of the fax destination, and preview the FAX and his cover sheet, which would be generated by the cover sheet generator. Many of our current users actually don't want any dialog to show or have any user intervention possible, for instance to handle server-side conversion. The control dialog application is still optionally launched, but despite its name it does not need to show a dialog.
What the control dialog can do is as follows:
It has been our intent to create a single API that will be consistent across all platforms. We feel that to a large extent we have succeeded. The same entry points, largely, are available in all versions of the IMGxxMFX.DLL library, the only significant difference being the use of Unicode in the DocInfo structure, and in the pipe name used in the MfxXxxEx() functions in IMG32MFX and IMG64MFX, where ANSI is used in the DocInfo16 structure and pipe name used in IMG16MFX. You can write in 16, 32, or 64 bits, with the assurance that your code will work the same whether it is running on Windows 95 or Windows 10. The Unicode / ANSI conversion is handled internally, so that IMG16MFX always uses ANSI even on a Windows NT platform, and IMG32MFX always uses Unicode, even in Windows 95 which supports Unicode only sketchily.
For most of our drivers, the print process is similar. Where in the process the print driver is actually invoked depends on settings that you make in the spooler. There are two main options:
Normally we recommend that you set the printer to place raw data in the spool queue, and our installer is set to do that by default. This is because, spooling to EMF, if you have a large print job in the queue ahead of you, there can be a significant delay between the time that the print job is created, and the time that the print driver gets control of it; and so it may be some time after the user has printed the image that the control dialog comes up and asks for additional information. Even rendering a page a second (as we do on an NT4 machine with a PII-266), a 60-page fax job would not clear the queue for a whole minute, and the control dialog could possibly not appear until a solid minute after the user had gone on to do other things.
There are side effects of this, of course. If set to RAW mode, the print driver is then officially part of the process that is doing the printing, and in Win9x a crash in the print driver (which has been known to happen) can crash the application doing the printing. In Windows NT4, Windows 2000, and Windows XP before SP2, the printer is actually running in Kernel mode, and effectively completely decoupled from the printing application, whether it is printing spooling to EMF or to raw data, which is better. However, this has the side effect that the driver can potentially can bring the entire computer down if it crashes; this is not something we at ImageMAKER are happy about, but it was a Microsoft design decision and we all simply have to live with the consequences.
With the printer set in RAW mode, the printing application calls down to GDI to render a page. These calls go directly to the print driver, which renders everything to a bitmap surface. When the page is finished, the printer driver then dumps the rendered surface to a file. Before it dumps the first page to the output file, the print driver invokes the control dialog. The name of the control dialog can be set by the user, but normally it is set initially at install time by the OEM, and the user will have no reason to change it. Typically the control dialog will appear almost instantly once the user starts the print job; and the printing will then continue once the control dialog releases the job.
With the printer set in EMF mode, the printing application calls down to GDI, which stores the call as an EMF entry in the spool queue. When the entry being created reaches the head of the spool queue, the print driver is invoked to render the EMF into printer-specific commands, and the print driver in turn invokes the control dialog. The overall process is much the same, except that the control dialog does not appear until later in the process.
The timing of the appearance of the control dialog can be important. Apart from the issue of how long your user is willing to wait, there is the additional question of how large the print job will be. When the control dialog is started, the only number it can report as the length of the print job is the current length of the print job, the number of pages that have been renderes as of the instant when mfxGetDocInfo is called. If the control dialog is called later, chances are higher that the image will be fully rendered and the page count will be accurate. It is possible to set the spooler to not pass the EMF to the print driver until it is fully queued; this is done with the Schedule entries in the printer properties pages.
For more specific details on individual platforms, select one of the links below: