iPrint jobs lacking features provided by the print driver

Advanced features (such as collating, watermarks, multiple copies, and others) either don't show as options when installed as iPrint printers, or they show as options and don't work.

Microsoft will accommodate this problem in their service pack releases. SP3 for Windows XP and SP5 for Windows 2000 will contain the necessary change. In conjunction with applying the Microsoft service pack you must apply the 3.12 iPrint client or later. After applying both the Microsoft update and the 3.12 iPrint client, you must re-install any iPrint printer to the Windows workstation that is affected by this problem. Go to Novell's File Finder at https://support.novell.com/filefinder and search for NIPP.EXE to find the latest version of the iPrint client.

For those who cannot wait for the service packs to be released, you can call Microsoft at 1-800-936-4900 and refer to KB 884897. Additionally, you can view KB 884897 by going to http://support.microsoft.com/default.aspx?scid=kb;en-us;884897 and view the contents of that document.

You do not need to upgrade the NDPS client to benefit from the fix provided by Microsoft.

HISTORY

The example used in this explanation is the collation feature. However, other features fall under the same problem.

With the introduction of Windows 2000, the print spooling subsystems have been designed to potentially emulate output collation in cases where the vendor·s printer driver indicates collation isn't supported by the physical printer hardware itself. Prior to this more universal facility in Windows 2000, either the physical printer hardware or the specific application being printed from had to explicitly supply on their own the ability to produce multiple copies is collated order.

However, the manner in which this facility was implemented in Windows 2000 and Windows XP does not accommodate supplying the feature to printers that Windows accesses via a network print provider. As such, although Windows applications, printer vendors and customers may desire to leverage the hardware-independent collation ability Windows 2000 and later platforms provide, they will find this feature does not work in nearly every type of environment that required a network print provider.

This document intends to help explain how some of the relevant printing mechanisms work on Windows 2000 and later, under which configurations the emulated collation feature will and will not work, and what Novell has done to work together with Microsoft to address the issue.


HOW THE COLLATION FEATURE GETS EMULATED ON WORKSTATIONS RUNNING WINDOWS 2000 OR WINDOWS XP:

The portion of the process employed relevant to this discussion is depicted in the ·Print Job Data Flow· diagram from the ·Display and Print Devices· section of the Windows DDK. (Either diagram shown; both the user-mode and kernel-mode implementations operate the same for this discussion.) The following discussion makes reference to these diagrams.

http://www.microsoft.com/technet/archive/winntas/plan/kernelwp.mspx?mfr=true

As shown at the start of the diagram, when the Win32 Graphics Device Interface (GDI) (·GDI User-mode Client·) wants to write print data to the print spooler, GDI will typically specify Enhanced Metafile (EMF) as the OUTPUT format. (The INPUT data coming from GDI is always EMF, as this is the ·language· in which GDI works.)

When the OUTPUT format is EMF, the data will be spooled to a local file. De-spooling of that file is then performed through the EMF print processor, which takes on the responsibility of turning the EMF data into printer-ready RAW output by invoking GDI and specifying that the output format needed is now RAW (meaning the data needs to be in printer-ready format, such as PCL, PostScript, etc.).

To accommodate the now-requested output format of RAW, GDI interprets the EMF data and invokes the vendor- and/or language-specific printer graphics DLL component of the printer driver to generate the RAW information needed to represent that data. The newly generated RAW data stream is then sent on for delivery to the physical printer.

The point within this process where the collation feature is potentially emulated is in the invoking of the EMF print processor to ·play back· the spooled EMF data. The EMF print processor may choose to submit the EMF data to GDI in a way that emulates the desired features, such as submitting the document data multiple times serially to create the collated output effect.


WHY COLLATION DOESN'T WORK ON NETWORK PRINT PROVIDERS:

As described in ·Overview of Partial Print Providers· (also from the ·Display and Print Devices· section of the Windows DDK), network print providers depend on the local print provider and its print processors to create RAW data that can be sent to a printer.

This is because most network print providers intend to transmit the print data to some type of non-Win32 platform where GDI would not be available to interpret the EMF data, nor will there be a vendor-specific printer driver available to generate the needed RAW data based on the EMF instructions. In other words, the print data needs to get out of its Windows-specific format before being transmitted to a non-Windows platform.

In response to this need, the Windows print spooling subsystem (including pre-Windows 2000 platforms) will reject the Win32 GDI·s attempt to generate data with an OUTPUT format of EMF. This in turn means that the spooling of the EMF data to a file will never occur for this data.

Instead, the Win32 GDI interface will switch immediately to an output format of RAW. As such, since the OUTPUT format is now RAW instead of EMF, GDI will take the EMF input data and invoke the vendor- and/or language-specific printer graphics DLL to generate the RAW information. The Win32 GDI itself performs this, instead of depending upon the EMF print processor to request the RAW format later during playback of the EMF data.

The end result is that RAW-format data gets generated for shipment to the network print provider·s printer that has not gone through the steps that would have inserted the emulated features into the data stream. So the network print provider has the RAW-format data needed for shipment to a non-Windows platform, but without the features that would have been added if the RAW-format data had been generated by the path taken for non-network printers.

As such, features that would have been emulated during the EMF processor playback do not appear for any Windows 2000 or Windows XP installed printer that uses a network print provider · ANY network print provider. This includes Novell·s iPrint, NDPS and NetWare queue-based print providers for Windows 2000 & XP; but also includes any other third-party print provider and even Microsoft·s own Internet Print Provider (IPP) and also the Windows LanMan print provider (when printing to remote shared printers hosted by non-Windows 2000/XP servers). Using any of these print provider scenarios on Windows 2000 or Windows XP client workstations will fail to achieve emulated features such as collation.


WHY COLLATION WORKS ON SHARED WINDOWS 2000 AND WINDOWS XP PRINTERS:

When printing to a remote Windows shared printer, the local Windows client workstation will essentially ship the EMF data over to the print spooling subsystem of the Windows server that is sharing the printer.

Technically, the print data has left the Windows 2000 or Windows XP client workstation without having the EMF playback-emulated features added, just as happens in the printing scenario for any other network print provider·s printer.

However, because in reality the client workstation is effectively submitting their EMF-based print job into the print spooling subsystem of the remote Windows server, there is still opportunity for the EMF print processor to get invoked over on the Windows SERVER, at which point the features emulated during EMF print processor playback will be added (if the Windows server sharing the printer was a Windows 2000 or Windows XP platform).

In other words, although the Windows 2000 or Windows XP client workstation treated the LanMan print provider no differently than other network print providers and did not add the collation feature prior to shipping the print data out from the client workstation, if the remote machine is a Windows 2000 or Windows XP platform then the collation feature gets added at that end where the printer IS just another local Windows printer (and it·s the print job that came from a remote source).


WH.Y COLLATION WORKS WHEN USING ·STANDARD TCP/IP PORT· AND OTHER PORT MONITORS:

Creating a new port using the ·Standard TCP/IP Port· (TCPMON.DLL) port monitor (or any other third-party port monitor, such as Hewlett-Packard·s ·HP JetDirect Port· HPLOCMON.DLL) is handled identically to any other local Windows printer. The only difference is that the local port being written to redirects the output to a network-connected device, same as how the Windows ·Local Port· port monitor would have directed the data out to a parallel- or serial-connected device.

As such, although Windows can be described as ·printing to a network printer· (because the network is being used to deliver data to the physical printer), there is no network print provider involved. (Only a port monitor that happens to direct it·s output to a network-connected device.) Since there is no network print provider involved, the path taken to generate the RAW-format for delivery to the printer includes the steps that add the emulated features such as collation.

Without a network print provider involved, all Windows knows how to do is send data out to the network-connected device via the port monitor. Trying to list or manage jobs for that printer will only show the jobs the local Windows workstation is still in the process of writing out via the port monitor.

The manner in which a network print provider plugs into the overall Windows print architecture is what provides the ability to truly see and manage jobs on a remote network print server platform, such as a remote Novell NetWare server, a Novell Distributed Print Services Manager, or other examples such as a Unix-based host running LPD. Using a port monitor will not allow the Windows workstation to see or manage the jobs already in queue out on the print server, or to leverage additional management features the remote print server platform may provide.


WHAT NOVELL HAS DONE TO ADDRESS THE ISSUE:

Although Novell would concur that the Microsoft print provider is functioning as designed (in other words this is not a failure due to product or component defect), based on the above described understanding of the mechanisms and issues involved, Novell·s perspective is that the path taken to generate RAW data for network print providers is not inherently precluded from having the EMF print processor-generated features added; only that the involved subsystems are not currently designed to apply those features in all cases where RAW print data is being generated.

As such, Novell considers this to be an issue affecting not only Novell customers and users of Novell print services, but also as an issue any customer, application vendor and printer driver publisher that expects their end-user experience to be consistent regardless of whether they are using their Windows 2000 or Windows XP client workstation in an environment where a network print provider talking to a non-Windows 2000 Server system had to be employed.

Novell has opened up a formal request for enhancement with Microsoft to continue evolving the print system implementation such that the EMF print processor-emulated features will be present in the RAW data stream delivered to network print providers. This request for enhancement with Microsoft is DCR 4195 and is titled"Collate feature does not work with any non-LanMan network print provider". If you are interested in this request for enhancement, Novell suggests that you contact Microsoft and provide Microsoft with your additional business case information.

.

Formerly known as TID# 10070383