Welcome to ImageMAKERHome Product Information Component Info White Papers Specifications Technical Support Demo Download About ImageMAKER

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:

  • When it is started up, it receives on its command line some details about the print job. Some of these details are to be used in establishing and maintaining communications with the print driver; others are available for identifying and changing the characteristics of the print job. These details are:
    • The name of the print job (as -c"print job name")
    • In Windows 3.1, Windows 95, Windows 98, and Windows ME, the handle to a communications window (as -hnnnn, a four-digit hex number)
    • The port to which printing is directed (as -d"portname")
    • In Windows NT and Windows 2000, the name of a communications pipe (as -n"pipename")
    • The default file name for output, read from the registry (as -f"filename.ext")
  • Using the mfx_GetDocInfo() or mfx_GetDocInfoEx() entry points in the IMGxxMFX.DLL library, the control dialog can retrieve additional information about the print job. Information is returned in a DocInfo (Windows NT and Windows 2000) or DocInfo16 (Windows 3.1, Windows 95, Windows 98, and Windows ME) structure. The components of this structure are:
    • file_type: The compression type of the file. The following values are available:
      • -1: No output will be generated
      • 0: TIFF MH, image bits reversed (default, what GammaFax cards expect)
      • 1: TIFF MH, image bits in normal order
      • 2: Intel DCX
      • 3: ZSoft PCX
      • 4: TIFF MR 2D, image bits reversed
      • 5: TIFF MR 2D, image bits in normal order
      • 6: TIFF MMR (G4), image bits reversed
      • 7: TIFF MMR (G4), image bits in normal order
      • 8: TIFF PackBits
      • 10: Monochrome BMP
      • 200: TIFF Packbits 24-bit color RGB
      • 201: 24-bit color Windows bitmap
      • 202: JPEG (JFIF-format)
      Note that the last three of these values are only available on our color printers.
    • mppf: If TRUE, the file format specified contains multiple images ("multiple pages per file")
    • landscape; if TRUE, the first page of the image, or the printer default, is set to landscape mode. NOTE that this does not necessarily indicate the orientation of the entire print job, as the printer driver does include the capability to embed different orientations in the same output file.
    • form: The name of the current default form or the form for the first page of the file. In Windows NT and Windows 2000, this is a Unicode (wide character) string. For all other platforms, it is an ANSI or DBCS string, in English.
    • form_size: This is the size of the form measured in mm.
    • jobid: In Windows NT and Windows 2000, this is the spooler's ID number for the job. It is set to 0 in Windows 3.1, Windows 95, Windows 98, and Windows ME.
    • printer: This is the "friendly name" of the printer. In Windows NT and Windows 2000, this is a Unicode string; for all other platforms, it is an ANSI or DBCS string in the system local language (the same name as appears in the Printers folder).
    • doc: This is the name of the document, exactly the same as is provided by the -c parameter on the command line. In Windows NT and Windows 2000, it is a Unicode string. For all other platforms, it is ANSI or DBCS.
    • total_pages: For Windows NT and Windows 2000, this is the length of the print job, in pages, at the time mfx_GetDocInfo was called. For all other platforms, this field is currently 0.
    • Xdpi, Ydpi: This is the horizontal and vertical resolution of the generated image.
  • Using the mfx_SetFileType() or mfx_SetFileTypeEx() entry points in the IMGxxMFX.DLL library, the control dialog can change the compression type (using the constants mentioned above) and the mppf flag.
  • Using the mfx_MonitorPrint() or mfx_MonitorPrintEx() entry points, the control dialog can release the print job and retrieve a return code that indicates that the job has finished and whether it was successful.

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 both 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, where ANSI is used in the DocInfo16 structure and pipe name used in IMG16MFX. You can write in either 16 or 32 bits, with the assurance that your code will work the same whether it is running on Windows 95 or Windows 2000. 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:

  1. You can set the spooler to retain enhanced metafile data in the spool queue, and then render the data through the print driver as it is being despooled.
    • In Windows 95, Windows 98, and Windows ME this is done from the Printer Properties, Details tab, Spool Settings button; set the "Spool data format" to EMF.
    • In Windows NT4, this is done from the Printer Properties, General tab, Print Processor button; set "Print Processor" to "winprint" and "Default datatype" to "NT EMF 1.003".
    • In Windows 2000, this is done from Printer Properties, Advanced tab, Print Processor button; set "Print Processor" to "winprint" and "Default datatype" to "NT EMF 1.008"
  2. You can set the spooler to place raw printer data in the spool queue, rendering the data through the print driver as it is being spooled.
    • In Windows 95, Windows 98, and Windows ME this is done from the Printer Properties, Details tab, Spool Settings button; set the "Spool data format" to RAW.
    • In Windows NT4, this is done from the Printer Properties, General tab, Print Processor button; set "Print Processor" to "winprint" and "Default datatype" to "RAW".
    • In Windows 2000, this is done from Printer Properties, Advanced tab, Print Processor button; set "Print Processor" to "winprint" and "Default datatype" to "RAW"

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 and Windows 2000, 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:

Color printers: Windows 95 Windows 98 Windows NT4

Monochrome printers: Windows 3.1 Windows 95 Windows 98 Windows ME Windows NT3.51 Windows NT4 Windows 2000

line

Sales: (866) 525-2170 Toll Free in North America
Sales: +1 (604) 525-2170  
Support: +1 (604) 525-2108  
Fax: +1 (604) 520-0029
Local (Pacific) time: GMT-8

ImageMAKER Development Inc.
#102 - 416 Sixth Street
New Westminster, B.C.
Canada V3L 3B2

Copyright 2000 - 2008, ImageMAKER Development Inc. All rights reserved.
Legal information | Privacy policy | Contact information