 
 |
The Leader in TIFF Imaging Solutions |
|
|
Tech Note: The ImageMAKER Windows 2000 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 2000, 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 2000 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:
ImageMAKER Print Drivers are available for all Microsoft operating systems. The following single-user operating systems are supported:
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 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:
Citrix ships the following Terminal Server products, for which we have supported drivers:
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.
The following communication architecture is available to aid product integration with your custom application:
The information is stored in the registry at: 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:
Additional registry values added at release build 167:
Additional registry value added at build 173:
Additional registry values added at build 176:
Additional registry value added at build 187:
Additional registry value added at build 190:
Additional registry value added at build 191:
Additional registry values added at build 201:
Additional registry values added at build 208:
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
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 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. 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 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. 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. 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:
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 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 The NT print driver has two timeouts. The timeouts are set up to detect the following:
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 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: 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: 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; 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. 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 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.
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 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. 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: 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: 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: 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:
Support for Windows Citrix XP Published Applications: To support Published applications in Citrix XP:
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).
|
||
