Environment
Windows XP
Novell Distributed Print Services
iPrint
Situation
Resolution
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.Additional Information
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