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

The Leader in TIFF Imaging Solutions






Tech Note: The ImageMAKER Windows 2003 Server Terminal Server Print Driver

The Print Capture Driver is designed to easily integrate into any fax application. Four modules are defined in the print driver proper: the Print Driver, Print driver UI, Port Monitor, and Port monitor UI components. Additionally, as with our 16-bit print driver components, there is a Control Dialog. ImageMAKER Print Capture is responsible for capturing print commands to an in-memory bitmap. The Fax File API, which is integrated into the print driver components, controls writing the bitmap to a TIF, BMP, DCX, or PCX image file format. The Control Dialog provides the per-print-job 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. To integrate ImageMAKER Print Capture into your environment, all you need do is modify the Control Dialog. Plenty of source samples are provided in C, Visual Basic, and Delphi.

The control dialog may be spawned in system security context, or in the security context of the user who created the print job. Note that the latter is security context only; it does not include drive mappings or logged-in drives, and control dialogs do not have access to the registry mappings for the user via the HKEY_CURRENT_USER alias. However, you can retrieve the users name and SID, and from the retrieved SID find the subkey of the HKEY_USERS registry key that corresponds to this user.

In the system security context, the spawned application does not have access to information about who it was that created the print job. This is provided for those people who need to use a 16-bit control dialog; normally, a 16-bit application starts up in a system VDM, and if a 16-bit control dialog is started in a user VDM, it cannot communicate with any existing 16-bit applications.

If it is necessary to force starting a 16-bit control dialog in a separate VDM, this option is available in the printer options as well.

Because the control dialog does not inherit the drive mappings or logged in drives of a user, we have provided the ability to specify the name and password of an arbitrary user who should have read access to a share on a server where the control dialog executable exists, and read/write/create access to a share on a server where output files are to be placed. These shares do not need to be on the same server, but the same user ID and password are to be used for both. Note that this is the actual password on the server, not the Windows password: the Windows password is used to decrypt a file containing passwords for other shares in the normal course of events, and we do not have access to this cached password file at this time. If the name of the control dialog is specified as a UNC name (\\server\share\fax\execute\img32dlg.exe, for instance), and the printer option "Access specific share on server" -- "Use specific server account" is Enabled, the specified user name and password will be used to log on to the share \\server\share, and the control dialog will be read from that share. Note the following: The password is not stored in particularly secure form in the registry; we recommend that no sensitive data be stored in shares accessible to the user ID that is used by the driver.

A Control Dialog Executable is normally specified at install time; the installer provided accepts a control dialog name as one of its command line parameters, and sets the registry appropriately. In Windows 2003 Server, the registry is used for storage of all printer defaults. The printer UI component will allow you to change most of them; this is accessed in Windows 2003 Server through the Printers folder: locate the printer, right-click on it, and select Properties; then on the resulting multi-tabbed dialog, select Device Settings; or from the right-click menu select Printing Preferences..., and the Advanced button.

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.

The print capture driver is currently configured to support:

  • Any form size defined on the server where the driver is installed;
  • Landscape and Portrait orientation
  • Regular (204x98) and Fine (204x196), plus true 200x200 dpi resolution; higher and custom resolutions are available by special request
  • TIF (Gamma, Brooktrout, Group 3 and 4, MH, MR), DCX (Intel), PCX and BMP formats; scanned PDF and PNG formats are available
  • Multi-page files, or one page per file

Supported Operating Systems

ImageMAKER Print Drivers are available for all Microsoft operating systems. The following single-user operating systems are supported:

  • Microsoft Windows 2003 Server
  • Microsoft WIndows XP (Pro and Home)
  • Microsoft Windows 2000 (Pro, Server, Advanced Server, and Datacenter Server)
  • Microsoft Windows NT 4.0
  • Microsoft Windows ME
  • Microsoft Windows 98 and 98SE

The following single-user operating systems are no longer supported by Microsoft. As such, while we still can provide drivers for them and do some limited troubleshooting, support is very limited and we can offer few guarantees.

  • Microsoft Windows NT 3.51
  • Microsoft Windows 95, 95a, 95B, and 95C
  • Microsoft Windows 3.1

Microsoft uses a technology called Terminal Services to provide multi-user support in its operating systems. For these platforms, because of its multi-user nature, a different driver architecture is required. Microsoft ships the following Terminal Server products, for which we have supported drivers:

  • Microsoft Windows 2003 Server
  • Microsoft Windows 2000 Server
  • Microsoft NT 4.0 Windows Terminal Server

Citrix ships the following Terminal Server products, for which we have supported drivers:

  • Citrix MetaFrame XP for Windows 2003 Server
  • Citrix MetaFrame XP for Windows 2000 Server
  • Citrix MetaFrame XP for Windows NT 4.0 Server, Terminal Server Edition
  • Citrix MetaFrame 1.8 for Windows 2000 Server
  • Citrix MetaFrame 1.8 for Windows NT 4.0 Server, Terminal Server Edition
  • Citrix MetaFrame 1.0 for Windows NT 4.0 Server, Terminal Server Edition

Citrix has also shipped the following operating systems. These are based on the Windows NT 3.51 operating system, which is no longer supported; and these Citrix versions are also unsupported. While we can provide drivers for these platforms, and do some limited troubleshooting, support is limited and we can make no guarantees.

  • Citrix WinFrame 1.8
  • Citrix WinFrame 1.7
  • Citrix WinFrame 1.6

Print Capture Integration

The following communication architecture is available to aid product integration with your custom application:

  1. On start of print, Print Capture reads the contents of the registry, to find the defaults for the printer.
  2. If a Control Dialog is specified, then print capture calls this executable, and waits for a response message. The response message defines the name of the file to output to, or returns an empty string.
  3. If a Control Dialog is not specified, then print capture outputs to the default file name as specified in the registry.

The information is stored in the registry at:
HKLM/
  System/
    CurrentControlSet/
      Control/
        Print/
          Printers/
            <Printer Driver Name>/
              PrinterDriverData
All the data is stored either as REG_SZ (string) or REG_DWORD (longint) types. The names and functions of the values are described below.

Included with ImageMAKER Print Capture is a sample Custom Control Dialog application IMG32DLG.EXE (Visual C Example) which is called by ImageMAKER Print Capture. Source to this application is provided as part of the object license.

The application makes a call to IMG32MFX.DLL to handle communication with the ImageMAKER Print Capture Driver. When ImageMAKER Print Capture has completed the print capture process, it notifies the Control Dialog with a status message, including number of pages written or error return code. The maximum number of lines per page may be requested by a call to another routine; this can be used to determine whether the image sent was high or low resolution.

Supported fields within the registry are as follows:

  • "Color Mode": REG_SZ, controls dithering and handling of halftones. This takes on the following values:
    • "Monochrome (faster, less memory)"
    • "Color - All Colors to Black"
    • "Color - All Colors to White"
    • "Color - Dither from 256 Colors"
    • "Fast dither using Windows dithering"
    Starting with build 192, the following values are also supported:
    • "Error diffusion dithering": Use error diffusion as the dithering technique, dither from 24-bit color.
    • "Noise mask dithering": Use blue-noise mask for the dithering technique, dither from 24-bit color.
  • "Debug Changed": REG_DWORD, set to 1 when the debug flags are changed. It triggers a later copy of the debug values from the printer area of the registry to the port monitor area of the registry. This is done because in Windows 2003 Server the driver runs in kernel mode and does not have access to the log file.
  • "Debug Flag": REG_DWORD, if set to 1, then debugging info is written to LogFile
  • "Dither Pattern": REG_SZ, specifies the dither pattern to use. This takes on the following values:
    • "8x8 (65 shades)"
    • "Big 8x8 (65 shades)"
    • "Circular 4x4 (17 shades)"
    • "4x4 (17 shades)"
    • "3x3 (10 shades)"
    • "Big 2x2 (5 shades)"
    • "2x2 (5 shades)"
    Starting with build 201, the following values are also supported:
    • "6x6 Diagonal"
    • "8x8 Diagonal"
  • "Driver Timeout": REG_DWORD, maximum timeout the control dialog has to respond. The control dialog communicates with the driver using a named pipe; this is the amount of time (in seconds) that the driver will wait for the dialog to connect before it proceeds.
  • "Erase Log Flag": REG_DWORD, if 1, erase Log file on driver initialization
  • "Fax Dialog Loc": REG_SZ, the fully-qualified name of the control dialog to launch
  • "File Type": REG_SZ, output file type; can take on the values:
    • "TIFF Group 3"
    • "TIFF Group 3 (2D)"
    • "TIFF Group 4"
    • "TIFF PackBits"
    • "Intel DCX"
    • "ZSoft PCX"
  • "Gray Intensity": REG_DWORD modifies the Grey intensity (the gamma value for conversion from color to gray-scale) when dithering is on. The value ranges from 0 (darkest) to 100 (lightest).
  • "Logfile": REG_SZ name of debugging info log file
  • "MPPF Flag": REG_DWORD if 1, allow Multiple Pages Per File (MPPF)
  • "NT Dither Pattern": REG_SZ Windows dither pattern. This controls the dither pattern used when Windows Fast Dither is selected as the "color mode", and takes on the following values:
    • "Windows 2x2"
    • "Windows 2x2 Modified"
    • "Windows 4x4"
    • "Windows 4x4 Modified"
    • "Windows 6x6"
    • "Windows 6x6 Modified"
    • "Windows 8x8"
    • "Windows 8x8 Modified"
    • "Windows 10x10"
    • "Windows 10x10 Modified"
    • "Windows 12x12"
    • "Windows 12x12 Modified"
    • "Windows 14x14"
    • "Windows 14x14 Modified"
    • "Windows 16x16"
    • "Windows 16x16 Modified"
  • "Output Directory": REG_SZ default directory location of output file
  • "Output Prefix": REG_SZ first 4 letters of the output file
  • "Permission": REG_DWORD used only by the driver to determine whether a given user can change driver settings. Does not affect driver behaviour.
  • "Reverse Fill Flag": REG_DWORD GammaFAX format requires TIFF reversed bits (bits reversed within the byte); on all G3/G4 TIFF formats we provide this as an option.
  • "Separate VDM": REG_DWORD if 1, will spawn 16-bit control dialog in separate memory space; if 2, will force common VDM; if 0, will use default setting from WIN.INI.
    NOTE: Starting, we believe, with SP4 of NT4, the "Separate VDM" value 0 ("Run in separate memory space: Disabled" in the printer properties) triggers an Illegal Parameter error (log entry: "Spawn from faxmon.dll failed for app: xxx (87)") if you are attempting to launch a 16-bit application in the User security context (which requires a separate memory space). We have changed the UI to prevent this situation from being created by the user, and modified the driver so that selecting "Run in separate memory space: Disabled" silently forces System security context.
  • "Server share flag": REG_DWORD if 1, will use specified user ID and password for connection to server
  • "Server share password": REG_SZ encrypted password for server share
  • "Server share username": REG_SZ name of user for server share
  • "Spawn in User Context": REG_DWORD if non-0, will spawn control dialog in user rather than system security context (but see "Separate VDM", above)

Additional registry values added at release build 167:

  • "FaxBatch Library": REG_SZ name of the library to load for FaxBatch (if supported by the driver); searches the system path for the specified library if no path is provided
  • "Left Margin": REG_DWORD image is shifted rightwards by the specified number of pixels. Note that this value is not used after built 208.
  • "Second Timeout": REG_DWORD the driver will now time out if there is a long interval between successive calls to the mfx_Xxx()routines; this value is the number of seconds for that timeout
  • "Subfiletype Flag": REG_DWORD which controls the use of the TIFF NewSubtype tag, as follows:
    • if 0 (default), single page TIFF files have this tag set to 0, multipage files have the tag set to 2;
    • if 1, all TIFF files have this tag set to 0;
    • if 2, all TIFF files have this tag set to 2 (COMMETREX file type).

Additional registry value added at build 173:

  • "Check for Daemon": REG_DWORD if absent, or 0, we do not do the check for a daemon on the desktop. Defaults to Absent. See "RightFax drivers" for details.

Additional registry values added at build 176:

  • "CSID Enable": REG_DWORD. If non-0, a CSID is printed at the top of the page.
  • "CSID Name": REG_SZ one part of the string that is printed on the top of the page, notionally the name of the sending person or organization.
  • "CSID Number": REG_SZ one part of the string that is printed on the top of the page, notionally the phone number of the sending person or organization.

Additional registry value added at build 187:

  • "No rotation": REG_DWORD if non-0, landscape images are not rotated to make them fit the standard FAX format; they come out of the print driver as 11x8.5" pages.

Additional registry value added at build 190:

  • "Overwrite": REG_DWORD. Following values are supported:
    • 0 - Do not overwrite; attempt to create a new file of the same name as an existing file will fail
    • 1 (Default) - Overwrite if another file of the same name exists.
    • 2 - If a file of the same name exists, and it is a TIFF file, append the new image to the existing file (TIFF file formats only).

Additional registry value added at build 191:

  • "NumberOfEols": REG_DWORD, number of EOLs to use as a marker for the end of a page in G3 TIFF formats. Defaults to 1 if not present. Other standard values are 0 and 6.

Additional registry values added at build 201:

  • "Dither Offset": REG_DWORD, whether the dither pattern should be skewed (used only when color mode "Color - Dither from 256 colors" is selected). Defaults to 0 (no skew) if not present.

Additional registry values added at build 208:

  • "Emulation": REG_SZ, the name of the printer we are currently set to emulate. Used for display only.
  • "Exact Printing": REG_DWORD, whether What You Print Is What You Fax is enabled. Defaults to 0 (disabled) if not present.
  • "Source Depth": REG_DWORD, the number of bits to use in the gray-scale re-rendering of images if What You Print Is What You Fax is enabled. Defaults to 8 if not present; other legal values are 1 and 24.
  • "Source Resolution Exact": REG_DWORD, the default resolution to be reported to Windows when exact printing is enabled. High word is X resolution, low word is Y resolution.
  • "Source Resolution Std": REG_DWORD, the default resolution to be reported to Windows when exact printing is disabled. High word is X resolution, low word is Y resolution.
  • "Target resolution": REG_DWORD, the output resolution used when What You Print Is What You Fax is enabled. High word is X resolution, low word is Y resolution.
  • "Unprintable Bottom", "Unprintable Left", "Unprintable Right", "Unprintable Top": REG_DWORD, Unprintable areas on all four sides of the page. Value is in thousandths of an inch; defaults to 0 if not present.

Specific Known Issues and Workarounds

Although there is a minimum allowable page size, we do not currently enforce it. If you print a page smaller than the smallest allowable size, you will get an error and possibly a blank printout.

We do not recommend setting the Scheduling value to "Print direct to port". Our installer defaults to setting the value to "Spool print documents so that program finishes printing faster" and "Start printing immediately". For the reasons behind this choice, see the section on "Printing Directly to the Printer".

If you specify Print To File, the driver will create a Windows Bitmap (BMP) file, and will not spawn the control dialog. Compression is not properly handled in this case. Note that the resulting bitmap will have the Top-Down flag set in some versions of the driver, which makes the resulting file unreadable to most viewers. The Top-Down flag is a new feature of NT4. If you are using the FaxBatch driver, the embedded text information will make the resulting file unuseable to all viewers. We do have a utility that will convert the resulting inverted BMP to TIFF; contact for details.

If you stop and start the spooler with debugging turned on, some versions of our driver fail to load; we believe this is a timing issue. The symptoms are a title of the form "Failed to open - retrying" on the printer status box for our printer, and "The test page failed to print... The handle is invalid" in the message box that appears when you attempt to print a test page. You cannot use the printer properties page to turn off debugging because the printer properties page refuses to load. You must go into the registry; with RegEdit or RegEdt32, locate the key
HKEY_LOCAL_MACHINE/System/CurrentControlSet/Control/Print/Monitors/%s/Debug
where %s is the name of the fax port monitor, most commonly "Fax Monitor Port" or "FaxBatch Monitor Port". In this key, locate the value "DebugFlag" and reset it to 0. Now (stop and) restart the spooler.

Excel and the Overwrite Flag

Microsoft Excel will occasionally, for no reason that we can see, break a single printout into two or more print jobs. The Overwrite flag was specificaly altered to handle this situation; a second printout having the same name can be assumed, usually, to be an additional section of the same print job, and should be appended to the previous job. The control dialog can be set up to have some persistence of data structures, so that it knows that an additional print job has been generated by Excel, and appends the two print jobs, only sending the appended set of jobs off when they are complete. Our suggestion for this is to wait for 10 seconds to see if there is another print job; Excel seems to launch its print jobs in short order after it has managed to get all its ducks in a row.

Adobe Acrobat, Aldus PageMaker, Microsoft Office 97 (pre SR-1), Microsoft Office 2000 (all versions) and Corel WordPerfect 6 and 7

These applications do their own font handling and do not seem to be able to handle printer pixels that are not quite square. Microsoft Office 97 actually replaced a Windows component that could handle non-square pixels with one that could not; this is one reason that a service release of Office 97 had to be made. If you must produce printouts with these applications, and are getting unuseable output because of this problem, selecting "True 200x200 resolution (for Office 97)" in the device settings will eliminate the problem. Contact for details.

Office 2000 seems to only have this problem when dealing with table backgrounds. When a background color is selected, the program calculates a position for the text based on the resolution, and determines where a cutout for the text should be. It then draws the text, and later draws the background. The cutout position is miscalculated, however, because that part of the program does not correctly account for non-square pixels. The result is that background is drawn over the text and the text disappears. This problem is apparent in Microsoft Word 2000 GA, SR1, SR1a, and SR2.

RightFax drivers:

The RightFax drivers come in two varieties, one that uses an HP LaserJet driver to create PCL files which are then converted to TIFF, and one that uses an older OEM version of our driver to generate TIFF directly. Both of these are designed to communicate with the RightFax control center, which is based on the version of our desktop daemon that was current at the time. The communication technique with the desktop daemon has changed since then, so if the RightFax control center is running, driver versions between 108 and 172 will halt, waiting for a response from the daemon that will never come.

In the version 173 and later drivers, we have changed the driver so that it does not, by default, look for a desktop daemon before it proceeds. There is a registry setting that can be used on a per-printer basis to override this behaviour.

This does have one side-effect, however. If our driver is installed on a system which already has a RightFax printer using our direct-to-TIFF drivers, the RightFax driver will now not look for the control center, and so will not be able to print. Unfortunately, since the driver - to - daemon communications have changed, even re-enabling the driver's daemon check will not allow the RightFax driver to print successfully. We are attempting to reach an agreement with RightFax that will allow co-existence with our later drivers.

This problem does not affect the RightFax driver that uses PCL-to-TIFF translation.

Funk Software Proxy Host:

It has been reported to us that version 3.0 of the Funk Software Proxy product prevents installation of our driver. Two different error messages have been reported:

  • The instruction at "0x77801a13" referenced memory at "0x133f133f". The memory could not be "read".
  • Printer install failed 1801 (may also include the text "The printer name is invalid.")
We have traced this to a port monitor which the Funk Proxy host installs but does not remove when it is uninstalled.

If you are using the Proxy Host, the recommended solution is to download and install the latest version of their software; install has been tested with the version 3.07 host software and it works reliably.

If you have removed the Proxy Host from your machine and are no longer using it, the only solution is to edit the registry. Note that editing the registry can cause your computer to fail. If you choose to follow this course, open the registry with either RegEdit or RegEdt32 and navigate to
HKEY_LOCAL_MACHINE/
  System/
    CurrentControlSet/
      Control/
        Print/
          Monitors/
You will find a registry key there named "Proxy Remote Printing". Delete that entire key, and reboot your system. The ImageMAKER printer should then install without difficulty.

Multiple Landscape Pages

Printing a document on a Windows 2000 system that starts with a portrait-oriented page, then switches to landscape in the middle of the job, will end up printing landscape pages after the first in portrait orientation, with the page information squeezed and stretched to fit a portrait-format page. A print job that starts with landscape-format pages, then switches to portrait mid-job, will show the same problem on the second and subsequent portrait pages. Microsoft has confirmed that this is a bug in Windows 2000 that still exists as late as SP2. Please contact for a work-around.

Driver Timeouts

The NT print driver has two timeouts. The timeouts are set up to detect the following:

  1. The control dialog never launches
  2. The control dialog launches, but never calls mfx_MonitorPrint

Default timeout values are set at install time. The first timeout can also be modified by the user through the print driver interface.

The first timeout is meant to detect the case where the Control Dialog fails to launch. The second timeout is meant to detect the case where the Control Dialog crashes after launching. In either case, the timeouts are designed to 'restart' the process, allowing subsequent jobs to be processed. The timeouts can be defeated by setting them to 0 (infinite).

Timeout values are stored in the registry at
HKEY_LOCAL_MACHINE\
  SYSTEM\
    CurrentControlSet\
      Control\
        Print\
          Printers\
            <printer name>\
              PrinterDriverData
    "Driver Timeout"=dword:0000003c
    "Second Timeout"=dword:00000258

In order to inform the driver that the dialog launched correctly, we recommend that the Control Dialog call mfx_GetDocInfo() or mfx_GetDocInfoEx() after being launched. The second timeout can then be set to a large number once you are confident that your Control Dialog application is robust, and does not crash.

To modify the timeout values from within the installer, look for the DoPrinterInstall() function in instfax.c. In that function, there are references to:
  Printer.FirstTimeout = 60;
  Printer.SecondTimeout = 600;

Default Printer Resolution

Except for some custom versions of the driver, at installation the driver defaults to high resolution FAX (204x196). For some applications, this is not the desired resolution. Some sites will want to set the default resolution to Normal Fax (204x98); some sites have requested other resolutions and may want to set the resolution default to one of their custom values. We can provide a driver that defaults to any resolution; this default can also be set by making a trivial change to the installer INSTFAX.C that we have provided.

In the installer code, locate the following:
  Printer.DefaultRes = 2;
  Printer.DefaultPage = DMPAPER_LETTER;
  Printer.Orientation = 0; // Portrait
To set Normal Fax (204 x 98) as the default resolution, set DefaultRes to 1; for 200x200 square pixels, set DefaultRes to 4; 2 is Fine Fax (204 x 196). The constants available are documented in the header file INSTALL.H (comments on the structure INSPRINTER_2), and in the installer DLL documentation INSTALL.RTF. The page size can be changed by changing the value of DefaultPage; for the names of the paper size constants, you will need to check the Windows SDK for the paper size constants used in the DEVMODE. The orientation values supported are 0 (Portrait) and 1 (Landscape).

If you wish to change the default resolution programmatically, after you have installed the driver, you must first open the printer using the OpenPrinter() call; get the default DevMode for the printer using the GetPrinter(..., 2, ...) call; change the resolution; confirm that the DevMode is valid; and then set the default DevMode using the SetPrinter() call. The following code fragment does this:

PRINTER_DEFAULTS pd;
HANDLE hPrinter;
PRINTER_INFO_2 *pPi2;
int pi2size;

pd.pDatatype = NULL;
pd.pDevMode = NULL;
pd.DesiredAccess = PRINTER_ALL_ACCESS;
OpenPrinter("Fax Printer", &hPrinter, &pd);

GetPrinter(hPrinter, 2, NULL, 0, &pi2size);
pPi2 = (PRINTER_INFO_2 *) LocalAlloc(LPTR, pi2size);
GetPrinter(hPrinter, 2, (LPBYTE) pPi2, pi2size, &pi2size);

pPi2->pDevMode->dmYResolution = 98;
pPi2->pDevMode->dmPrintQuality = 204;
pPi2->pDevMode->dmFields |= DM_PRINTQUALITY | DM_YRESOLUTION;

ret = DocumentProperties( (HWND) 0, hPrinter, PrinterName,
  pPi2->pDevMode, pPi2->pDevMode, DM_IN_BUFFER | DM_OUT_BUFFER);
SetPrinter(hPrinter, 2, (LPBYTE) pPi2, 0);

ClosePrinter(hPrinter);
LocalFree( (HLOCAL) pPi2);

For this code to have the desired effect, you must have administrative access to the printer. This is the actual code used by the new installer DLL, except that error checking has been removed to make the structure of the functional calls more obvious.

The same technique may be used to change the default form size and orientation.

Selection of Forms

When we create the initial default DEVMODE, and when we are asked to confirm a DEVMODE, we set all of the available fields to indicate the paper size -- the paper size in mm, the paper name, and the form index. When Office 97 requests a change of paper, it resets only one of these fields, the form index, and leaves the flags set on all the size fields. This results in an invalid DEVMODE, one which specifies the form as DMPAPER_LEGAL, the form name as "Letter", and the size as 8.5 by 11 inches, and that all these size fields are valid. Office 97 then asks us to determine an appropriate GDIINFO structure based on this DEVMODE. Prior to release 144, we would walk the list of supported forms in the system to determine the best fit. The first form we find is always "Letter", which matches the (supposedly valid) form name in the DEVMODE returned to us, so we report the correct GDI settings for letter output. This results in Office 97 truncating letter-sized pages if the printer default is set to Letter.

We have changed the way we determine whether a form passed in is valid; we now check the form index first, if the flag indicates that it has been set, and then walk the form list looking for a name match if we haven't found the specified form. This will correct the problem with Office 97, but may cause difficulty with some systems where custom forms are defined.

Dithering

Dithering is a technique by which you can mimic the use of colors that you don't really have available. For instance, if you have only the standard process colors, cyan, magenta, and yellow, you won't be able to print that lovely orange shade you wanted except by printing a mixture of magenta and yellow. The problem comes about when your inks are not transparent, when you can't actually mix them; you put the magenta one down on the yellow one, you will only see the magenta color. If you make smaller spots, and place them side by side, the viewer's eye may be fooled into doing the mixing for you. In fact, this is the process used by many magazines and all comic books.

This is particularly useful for FAXes, where you have only black and not-black as colors. Given a gray-scaled image, which can be generated from a color image by relatively simple and well-understood rules, you can determine for a given area how many pixels should be black and how many should be white in order to average out to the gray that you really want.

The process of dithering is always a trade-off; when you start with color and have to compress it to black and white, you will lose information. We have provided a number of alternatives to allow you to select the best dithering technique for your application.

There are basically two types of dithering available to you: ImageMAKER dithering, and Windows NT dithering. To implement Windows NT dithering, it is necessary that we report the printer as being monochrome; Windows itself will then do what is necessary to convert colors to black and white dither patterns. You have a choice of the size of the dither pattern to use; a larger dither pattern will allow more gray levels to appear on the receiver's fax machine, but will have a smaller amount of positional information -- it is hard to see anything smaller than the (for instance) 6x6 pixel dither size. However, many applications will see that the printer is reporting itself as being monochrome, and will change the way they handle text. Microsoft PowerPoint 97, for example, will print all text as black text on a white background, no matter what colors you selected in your presentation; and Word (either 95 or 97) will print all text as black on whatever background you have selected, converting (for instance) yellow text on a blue background into a totally unreadable black on dark gray.

NT dithering is selected by choosing the "Fast NT Dithering" option in the Document Settings or Device Settings pages of the printer properties.

ImageMAKER dithering is done by the driver, and takes significantly more time and memory. The driver reports that it supports 256 colors or 24-bit color printing, and allows the application to create a colored image; it then dithers the image down to a monochrome image using its own internal techniques and prints that. Since the printer reports that it can handle color, the applications typically will print colors to the printer, and the output image will be very close to the image that appears on the screen. Because the image is realized twice, once to color and again from color to monochrome, the process does take longer; and the resulting output file will be larger as well, because it typically does contain more gray-scaled image information -- a dithered gray for a pale blue background, for instance. But the output fax image will be true to what appears on the screen. We also provide an Intensity slider to lighten or darken colors that would be printed in the middle of the output range; this has the effect of emphasizing dark or light colors.

ImageMAKER dithering is selected by choosing one of the following options in the Document Settings or Device Settings pages of the printer properties.

  • "Color - Dither from 256 Colors": This uses patterns that we have created to simulate larger and smaller pixels for varying values of gray. The patterns generated are unfortunately somewhat chunky, but are designed to compress moderately well using TIFF G3 and G4 compression. This increases transmission speed and decreases storage space at the cost of apparent image graininess and quality.
  • "Color - Error-diffusion dithering": This uses Floyd-Steinberg error diffusion (weights 7/16, 1/16, 5/16, 3/16) to produce the output dither pattern. The image is initially realized as 24-bit color, converted to a 15-bit gray scale, and then error-diffused. This produces a very pleasing image, but quite often the resulting image contains alternating 0 and 1 pixels, which is the worst possible pattern for G3 compression, and often results in the image actually being expanded to larger than it would be if no compression were applied. NOTE that some FAX modems cannot deal with scan lines in images that are longer than some fixed amount, often 512 bytes; a 50% gray scan line rendered with error diffusion (which will have alternating black and white pixels) will be 1944 bytes long.
  • "Color - Noise-mask dithering": This uses Ulichney's blue noise mask to produce the output dither pattern. The image is initially realized as 24- bit color, converted to a 15-bit gray scale, and then compared against a generated blue-noise mask. This produces a very pleasing image, but quite often the resulting image contains alternating 0 and 1 pixels, which is the worst possible pattern for G3 compression, and often results in the image actually being expanded to larger than it would be if no compression were applied. NOTE that some FAX modems cannot deal with scan lines in images that are longer than some fixed amount, often 512 bytes; a 50% gray scan line rendered with blue-noise mask dithering (which may have alternating black and white pixels) can be as long as 1944 bytes.
Other options available are:
  • Monochrome: essentially a 1x1 dither; anything lighter than a medium gray comes out white; anything darker comes out black
  • All colors to black: Anything that is not white prints as black
  • All colors to white: Anything that is not black prints as white
For more information on ImageMAKER dithering, and sample output from each of the dithering algorithms, click here

Windows 2000 & 2003 Terminal Services

This print driver was developed and tested with Windows 2003 Server, with Terminal Services installed.

16-bit control dialogs are not supported on Windows 2000 & 2003 Terminal Services. Microsoft has evidently followed Citrix's lead, and has apparently modified the spooler so that it does not return control until the job has actually started processing; this is equivalent to selecting the setting "Print Directly to Ports" in the Printers folder, Properties dialog, Scheduling tab. Please read the section "Printing directly to the Printer". Because of this behaviour of Windows 2000 & 2003 Terminal Services, we recommend setting a minimum of 5 ports on any Windows 2000 & 2003 Terminal Services system; most users will not attempt to print from more than 5 16-bit applications simultaneously. Note that there is a separate WOWEXEC and hence a separate mutex for each user; ten users each printing from a 16-bit application on a five-port system should not cause a deadlock, although the sixth through tenth users will not be able to do any work with any of their 16-bit applications until their print jobs have started.

The actual number of printer instances required will depend on how many users there are on the system, and how much FAXing they actually do. For normal use, as mentioned above, we recommend a minimum of five printer instances; if there are no 16-bit applications in common use on the server, this can be dropped to two instances. We do not recommend running a single printer instance on a Windows 2000 & 2003 Terminal Services system; in that situation, there does seem to be some unpredictable loss of print jobs. We have had good luck using the rule of one printer instance for every ten to fifteen users. If there are users in the habit of sending out hundred-page FAXes, we recommend one additional printer instance for every two or three such users.

The Citrix technical support people indicated that there was no known way to determine the desktop from which a given print job had been generated. This remains true in Windows 2000 & 2003 Terminal Services. As a result, we have created a desktop daemon that is intended to be run on each WinStation at login. This daemon establishes a link to the driver for each desktop when the driver requests a control dialog be launched; the control dialog is then actually launched by the daemon. NOTE THAT IT IS NOT POSSIBLE FOR THE DRIVER TO LAUNCH AN APPLICATION DIRECTLY in Windows 2000 & 2003 Terminal Services because it does not have access to any desktop except the console; and the console is not likely to be actually in use. As a result, if the Windows 2000 & 2003 Terminal Services driver is unable to open communications with the daemon, no control / addressing dialog will appear; the print job will be cancelled.

The installer does include an option to automate installation of this desktop daemon, and will refuse to install the drivers on a Windows 2000 & 2003 Terminal Services system if a daemon has not been specified on the command line. See the batch file WTSSAMPL.BAT for information on how to include a daemon on the command line. The installer places the specified daemon in the global startup group, to ensure that each user gets a copy of the daemon run on ther desktop when they first log in.

Because of this, you will need a separate version of the drivers if you want to install on a Windows 2000 & 2003 Terminal Services system. The current version of the installer will detect whether it is being run on a Windows 2000 & 2003 Terminal Services system and will select a different set of driver files automatically. Note that the driver files have different names to support this behavior.

There is also a risk of file name collision if all users will be printing to the same directory. To minimize this problem, we have added code to the driver for Windows 2000 & 2003 Terminal Services that will allow limited parameter substitution in the output file name. If you include the string "%user%" in the path specified for the output file, that will be expanded to the login name of the user before it is passed to your control dialog. NOTE that this expansion IS NOT PERFORMED on the name returned from the control dialog, or on file names returned from the FaxBatch library.

To make administration easier, the driver will also create an output directory if it does not already exist. Thus, the administrator does not have to remember to create a custom output directory for the FAX driver when he adds a user to the Windows 2000 & 2003 Terminal Services host.

Reminder: When installing drivers in a Windows 2000 & 2003 Terminal Services system, you must execute the command
  change user /install
before executing our INSTFAX program, and execute the command
  change user /execute
afterwards. The installer program does not reliably remove the old version of the driver when it executes; in order to complete the installation of an upgraded printer driver on a Terminal Server system, you must reboot the system.

Operation of the driver is identical to our standard driver operation with one difference only:

The -n option is provided to the control dialog. This option is the name of the pipe to use for communication to the print driver, and must be provided to the mfx_MonitorPrintEx() (and other mfx_???Ex) functions. A new version of the sample control dialog is provided with the driver. Because multiple users may be attempting to communicate with the driver at the same time, the control dialog must have distinct pipe names to differentiate between print jobs. YOUR CONTROL DIALOG MUST BE REWRITTEN TO SUPPORT THIS COMMAND-LINE OPTION. Sample code is provided.

Printing Directly to the Printer

We strongly recommend against using the "Print direct to printer" setting, because we have found so many problems with it. The major issue that occurs is if you have a 16-bit control dialog, and you are printing from a 16-bit program, the 16-bit subsystem expects an immediate return from the StartDoc call, and is not prepared to be re-entered at that point. Because 16-bit programs are not re-entrant, there is a mutex (mutual exclusion object) in the 16-bit subsystem that will allow only one 16-bit application to run at a time, and evidently this mutex is not released by the thread that is calling StartDoc. When the 16-bit control dialog tries to load, the 16-bit subsystem (WOWEXEC.EXE) enters a deadlock state: the new application cannot be run because the printing application is holding the mutex, and the printing application will not release the mutex until the control dialog has run at least to the point where it calls mfx_MonitorPrint. This is also a problem if more 16-bit applications try to print simultaneously than there are ports defined; if you have a printer defined with four ports and set as Print Direct to Port, and you have five instances of a 16-bit application all trying to print to it, the fifth printing application does not release the mutex when it calls StartDoc, and so no other application can run, and so the other four printer ports never get cleared out. Terminating the fifth application should release the mutex, but we have found that in NT 3.51 it does not, and we have some suspicions about what happens in NT4 as well.

In addition, we have discovered a similar lockup that occurs when printing from Microsoft Internet Explorer 4.0x, even with a 32-bit control dialog. We have not been able to determine the reason for this, but we suspect that it is an artifact of the module load serialization.

Given these warnings, and being aware of the consequences, it is easy to change the actual setting in the installer program. In the routine install_fax_printer, there is a line that reads
p.Attributes = PRINTER_ATTRIBUTE_LOCAL;
         //0x40: Spool, start print after first page

Change this line to read
p.Attributes = PRINTER_ATTRIBUTE_LOCAL|PRINTER_ATTRIBUTE_DIRECT;
         //0x42: Print direct to port

This can also be changed at any time under program control by any user with administrative privileges, using the GetPrinter(.. 2, ..) call, changing the Attributes field of the PRINTER_INFO_2 structure as outlined above, and then using the SetPrinter(.. 2, ..) call. It can also be changed in the registry (HKLM\System\CurrentControlSet\Control\Print\Printers\<Printername>, the Attributes value (REG_DWORD, we set to 0x40, change to 0x42), but that change will not take effect until the spooler is restarted, and probably will not work unless the spooler is stopped when the change is made. (The spooler caches many details about the printers and writes them back to the registry at shutdown; this may be one of them.)

Alternately, it is possible to specify that the control dialog application should start in a separate VDM. The mutex is designed to prevent 16-bit applications from interfering with each other, and since 16-bit applications running in separate memory spaces are totally isolated from each other, each VDM has its own mutex. However, if your application depends on being able to communicate with some other 16-bit application on the users' desktop, remember that Windows messages also do not pass from one VDM to another.

If there is any way to work around a requirement that you change the scheduling, we strongly suggest that you do that instead.

Separate VDM

The driver optionally can start a 16-bit control dialog in a separate VDM, as described above, in order to avoid the problem of 16-bit subsystem re-entrancy. The DefaultSeparateVDM entry in the Windows section of the WIN.INI file is used to determine whether 16-bit applications load in a separate VDM by default, or whether they all load into a common VDM. If you specify either Use Separate VDM or Use Common VDM, we ignore this setting.

The flags that are used to force use of a separate or a common VDM will cause loading a 32-bit executable to fail. Because of this, we determine whether the executable file you have selected is a 16- or a 32-bit executable. If you select a 32-bit executable as your control dialog, the Separate VDM flag will be grayed out and set to Default. Note that if the executable file you have specified does not exist, we will assume that the control dialog is a 32-bit executable and will gray out the separate VDM option.

Due to the overhead involved with checking the executable file type, we do not check before spawning the executable. We check when the Printer Properties Device Settings page is entered, and when the executable file name is changed; we also check when the installer executes. Since the installer defaults to "Default" (0), normally this will have no effect; however, if you change the Separate VDM switch in the installer source code to either Separate or Common (1 or 2), and specify a 32-bit executable for the control dialog, the installer will silently reset the Separate VDM switch to Default (0).

If you change the control dialog from 16 to 32 bits by editing the registry, and have either Separate or Common VDM selected, the control dialog will fail to load. If you have Debugging turned on, there will be a line in the log file, of the form:
  Spawn from faxmon.dll failed for app: xxx (87)

Starting, we believe, with SP4 of NT4, the "Run in separate memory space: Disabled" setting triggers an Illegal Parameter error if you are attempting to launch a 16-bit application in the User security context (which requires a separate memory space). We have changed the UI to prevent this situation from being created by the user, and modified the driver so that selecting "Run in separate memory space: Disabled" silently forces System security context.

Printing to a Share on a Server

Printing to a share on an NT server is still being debugged. Not all of our clients are able to do this, and it is proving very difficult for us to discover why not. The error codes returned by the system do not point to any reasonable cause.

Note that printing to a machine in a domain requires a small change to the user ID. Specifically, validation for access to a machine on an NT domain is handled by the domain controllers; thus, if you are trying to access a share in an NT domain, you must prefix the user name with the name of the domain. In our offices, for example, there is a user TestUser on the ImageMAKER domain server. To access shares available to that user in the ImageMAKER domain, the user name TestUser will not work; if you have logging enabled, there will be entries in the log file similar to:

FAXPORT - CreateShare error for user TestUser share \\faxserver\testshare (from \\faxuser\testshare\fax\tmp\bbbb.tif)
FAXPORT - Unable to open connection to server: Error code 1312

To correct this, the user name must be changed to "ImageMAKER\TestUser".

We have found that if you later shift from printing to a workstation in the domain, to printing on a workstation not in the domain, that you must specify the name of the workstation you are printing to. For instance: If you specify the user as ImageMAKER/TestUser, you can then save files to any machine in the domain with all the rights and privileges of TestUser in the domain. If you then change the user name to TestUser, the domain remains assumed; you can print to any machine in the ImageMAKER domain with TestUser's privileges. If you try to connect to a machine outside the domain, eg. FAXSERV, a member of WORKGROUP, you must prefix the user name with the name of the workstation, e.g. FAXSERV\TestUser. If you simply set the name to "TestUser", you will still be fetching your authorization from the domain, and likely authentication will fail, even if there is an account for TestUser on FAXSERV.

It is possible to print to a share on a Novell server. Note that the user name and password that you provide to the printer driver have to be the name and password defined for you on that specific server. A lot of the signing in nonsense is handled for you by Windows, and all hides behind a single password; like so: I sign in as Charles with password green on my machine here. (Not really, but you get the picture.) While connected, I attach to Novell server \\peppercorn; my account on that server is chasw and the password is cayenne, so I tell NT to attach as chasw, password cayenne, and NT saves that information internally and I never see it again.

If I tell the printer driver to attach to \\peppercorn\faxshare, it doesn't have access to the passwords file where account name chasw and password cayenne is stored. That's why you have to tell it what the name and password are. If I tell it Charles and green, that doesn't help, because that is the ID and password that will unlock the passwords file, but the driver still doesn't have access to that file. So it tries to attach to the account Charles on the server \\peppercorn with password green, and fails.

If you have enabled logging, and you have the wrong user ID or password, you will see a report similar to the following:

FAXPORT - CreateShare error for user steve share \\wol\sys (from \\wol\sys\fax\tmp\bbbb.tif)
FAXPORT - Unable to open connection to server: Error code 1317

In this specific case, be certain that the name and password you have entered are the ones assigned by the system administrator on your Novell server, or that you have entered the password to which you have changed. Note that changing the password on your machine does not necessarily change the password on your Novell server.

Support for Published Applications

Citrix MetaFrame XP and Citrix MetaFrame 1.8 support published applications.

Terminal Services is a licensing addition to Windows 2000 Server and Windows 2003 Server. Before any Citrix Metaframe product will work on W2K or W2K3, you must license Terminal Services.

Microsoft Windows NT 4.0 Server, Terminal Server Edition (NT4S-TSE) is a separate product from Windows NT4 Server.

Citrix WinFrame 1.6, 1.7, and 1.8 are rewritten versions of Windows NT 3.51 Server. All the MetaFrame products are wrappers that ride on top of an existing Terminal Server / Terminal Services application. Our Terminal Services version will work with a Citrix wrapper around Terminal Services.

Note that there will not be a Terminal Services for Windows XP. XP is coming out as workstation only, and TS is for servers. Thus Citrix Metaframe XP will never work with Windows XP.

The main advantages of the Metaframe wrapper are:

  • ICA protocol (less network bandwidth than the TS standard)
  • Better load-balancing between servers and CPUs
  • Seamless applications

Support for Windows Citrix XP Published Applications:

To support Published applications in Citrix XP:

  1. Administrator first publishes the application.
  2. Administrator modifies the application string in the published application to support 'print to fax'.

When the user 'runs' the published application, the daemon is launched, which in turn runs the published application. When the user closes the application, the daemon goes away. We support all concurrency issues. From the user's point of view, nothing is different (except that faxing now works). From the Administrator's point of view, they have only one extra step to publish the application.

To support running applications from the desktop, the daemon has to be activated in the normal way (run with no command line, ideally started from the start-up group when the user signs on).

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