Chapter 7 - Printing
The primary focus of this chapter is on local printing from the Windows NT Workstation itself. But you can also provide printing to as many as 10 peer-to-peer connections with the Windows NT Workstation functioning as the print server.
This chapter begins with a glossary of terms used throughout the rest of the chapter. The glossary is followed by an overview of the Windows NT printing process and the flow of control. After you have a clear picture of the printing process and are comfortable with the terms, you can move on to read in-depth descriptions of each component of the printing architecture based on the network protocols and operating systems of your networked computers. The chapter concludes with sections on print security, troubleshooting, and some common questions and answers.
For additional information about printing with Windows NT 4.0 Workstation, refer to the following documentation.
Glossary of Printing Terms
A print device is the actual hardware device that produces printed output—what you call a "printer" in casual conversation.
Print-device resolution is measured in dots per inch (DPI). The higher the DPI, the finer the resolution.
A printer, or logical printer, is the software interface between the operating system and print device. The printer determines how the document gets to the printing devices (for example, by means of a local port or to a remote print share) and to other parameters of the printing process. A single printer can send print jobs to multiple print devices, and multiple printers can send jobs to a single print device. For more detail about printers and print devices, see "Planning How Users Access Printers" in Microsoft Windows NT Server: Concepts and Planning Guide. In the NetWare and OS/2 environments, this software interface is called a queue.
In Windows NT terminology, a queue is a group of documents waiting to be printed.
Print jobs are source code that contain both data and commands for print processing.
Print jobs are classified into data types based on what modifications, if any, the spooler must make to the job so that it prints correctly. For example, one data type requires no modifications, whereas another data type requires the addition of a form feed to the end of the job.
The print spooler is a collection of dynamic-link libraries (DLLs) that receives, processes, schedules, and distributes print jobs.
Spooling is only one of the processes performed by the spooler. Spooling is the process of writing the contents of a print job to a file on disk. This file is called a spool file. In the event of power loss during printing, the spool file prevents loss of data, ensuring that the print job can resume after power is restored. Despooling is the process of reading the contents from a spool file and sending those contents to a print device.
Rendering means creating a print job. An application calls the graphics device interface (GDI). GDI takes the document information sent by the application, calls the printer driver associated with the target print device, and creates a print job in the printer language of the print device. The print device has "firmware" that interprets the submitted printer language and creates a bitmap for each page.
A print server is the computer that connects one or more print devices to the network and shares them with other networked computers. A print server can also be a special hardware device that connects a print device to the network with a net tap on one side and a parallel or serial port on the other side.
This chapter presumes that the print server is a Windows NT 4.0 Workstation.
A downlevel server is a print server running a Windows product that is not Windows NT 4.0—for example, Windows for Workgroups or Windows NT 3.x.
Creating a printer means connecting to the print device, either over the network or over a serial or parallel port, naming the printer, and installing the printer driver. To create a printer, run the Add Printer wizard, and click the Local printer option. You'll be asked to install the printer driver, specify a port, and give the printer a name.
Connecting to a printer means connecting to the share on the computer that created the printer. To connect to a printer, run the Add Printer wizard, and click the Network printer option. You won't be required to install the printer driver. Only Windows NT and Windows 95 clients can "connect to" a printer shared out by a Windows NT 4.0 print server. Other print clients must "create" the printer shared by the Windows NT print server.
A print client is the computer that creates the print job sent to a Windows NT print server. The client can be a remote client sending the print job to the print server over a LAN. Or the client can be on the print server itself—a local client. This chapter presumes that most printing done with Windows NT Workstation is local.
A client application is any application that creates a print job. The client application can be local (on the print server) or it can be on a client computer on the network.
Network-interface printers are print devices connected directly to the network by means of their own network cards.
Print server services are software modules on the print server that receive print jobs and determine if the spooler should alter them. Different print server services support print jobs from various clients.
Printer drivers are software programs that enable applications to communicate fully and properly with print devices. Each print device can require unique codes and commnds to make available its special features, such as two-sided printing or custom paper sizes.
Anything described as local means that it exists on the same computer.
Overview of the Printing Process
This section provides a general overview of printing at a Windows NT Workstation. Although the primary focus of this chapter is on local printing from the Windows NT Workstation itself, you can also provide printing to as many as 10 peer-to-peer connections with the Windows NT Workstation functioning as the print server. For more information about network printing using a Windows NT 4.0 Workstation as a print server, see "Network Printing Using Windows NT Workstation" later in this chapter.
Print jobs are not simply data: They are source code that contains both data and the commands for processing the data. The client application (along with the graphics engine and the printer driver) creates print jobs. For example, Microsoft Word 7.0 combines data objects such as text, fonts, and graphics with information from a printer driver to create source code for a document—the print job.
Because each type of print client (for example, UNIX clients and Windows NT clients) creates print jobs a little differently, a variety of print server services are required to receive and prepare the jobs. Some print server services assign print jobs a data type, which tells the spooler whether and how to modify the print job in order to print correctly. Some services leave the data type blank (in which case the default data type in the Print Processor dialog box on the print server is assigned).
If you create a printer, the default data type is EMF (if the printer is a PCL printer) or RAW (if the printer is PostScript). To change the default data type, use the following procedure:
To change the default data type for a printer you have created
The following sections describe the different data types.
Print jobs from Windows NT clients are enhanced metafiles (EMF). Instead of the RAW printer data being generated by the printer driver, EMF information is generated by the Graphical Device Interface (GDI) before spooling. After the EMF is created, control is returned to the user, and the EMF is interpreted in the background on a 32-bit printing subsystem spooler thread and sent to the printer driver.
EMF files are more portable than RAW files. An EMF file can be printed on any print device, whereas a RAW file can be printed on only one print device model. In addition, the set of EMF files that represent all pages in a print job are typically smaller than a RAW file that contains the same print job.
The first portion of the print job's rendering is done on the client computer. The last portion is rendered on the print server. This is especially helpful when the print job is a very large file, because the client application is not tied up for the entire rendering time. This data type also ensures that fonts specified on the client computer are the same ones used by the print server.
The RAW data type tells the spooler not to alter the job at all—that the print job is ready to print as is. Most jobs from non-Windows NT Windows clients are the RAW data type.
RAW [FF Appended]
This data type tells the spooler to assume the job is from an application that does not append a form-feed character (0x0C) to the end of each job. Without a trailing form-feed, the last page of the job does not print when sent to a PCL print device. The spooler appends a form-feed character to the end of the print job but makes no other alterations. None of the print server services supplied with Windows NT assign this data type, but you can set the default data type in the Print Processor dialog box to this type so that it affects jobs from Windows Network clients.
RAW [FF Auto]
This data type is similar to the RAW [FF Appended] data type, but RAW [FF Auto] tells the spooler to check for a form-feed character at the end of the job. It does not add a form feed if one is already present, and it makes no other alterations. None of the print server services supplied with Windows NT assign this data type, but you can set the default data type in the Print Processor dialog box to this type so that it affects jobs from Windows network clients.
The TEXT data type tells the spooler that the job consists of ANSI text. The spooler uses the current print device driver to create a new print job that prints the text of the original job using the print device's factory default font, form, orientation, and resolution listed in the Document Properties dialog box. This is useful when the print job consists of simple text, and the target print device (for example, a PostScript printer) cannot interpret simple text jobs.
Text files consist of numeric values from 0 to 255, where each value is mapped to a particular character or symbol. Several character-mapping schemes (character sets) are in common use, and text files contain no indication of which character set to use when displaying or printing the file. The TEXT data type assumes the ANSI character set, so it might print some characters incorrectly if the application that created the job does not use the ANSI character set. Most character sets are identical for the values 0 through 127, so this problem usually affects extended characters (those with values from 128 through 255).
The following table shows five examples in which common character sets use different numbers to represent the same character. The PC-850 character set is commonly used by MS-DOS-based applications in Europe; ANSI is used by Windows-based applications; PC-437 is commonly used by MS-DOS-based applications in the United States; Roman-8 is the default PCL character set.
This data type indicates that the print job consists of PostScript code from a Macintosh client and that the target printer is a non-PostScript print device. The spooler interprets the PostScript code and creates a bitmap of the page. GDI32 and the printer driver can convert the bitmap into the language of the target print device.
Print devices are the machines we call "printers." They produce hardcopy output by interpreting the printer language and creating a bitmap for each page.
Print devices have their own input and output channels; jobs can be directed to input channels such as parallel or serial cables or network adapters. Output can be produced on different media, including paper, film, or fabric.
Print devices have their own internal processors which can be proprietary or general-purpose (such as the Motorola 680xx-series chips in Apple LaserWriter devices). Incoming data is stored in the print-device RAM, which can range from a few bytes to a hundred megabytes. Each print device has software stored in ROM, called "firmware," which interprets the programming language of a print job's source code. Examples of programming languages are PostScript, PCL, and HP-GL/2.
Printer drivers are the software that enables an application to communicate with the variety of available print devices, regardless of the device type, model, or programming language interpreter.
In general, printer drivers are composed of three files that work together as a printer-driver unit:
These three files work as a unit. For example, when you set up and configure a new printer, the interface driver queries the characterization data file and then displays the available choices. Then, when you print, the graphics driver queries the interface driver about your selections so that it can create the proper printer commands.
Printer drivers are generally not binary-compatible across hardware-processor platforms. Consequently, printer drivers must be installed on the Windows NT print server for each Windows NT and Windows 95 client hardware platform. For example, when x86-based clients running Windows NT Workstation are served for printing by a Digital Alpha AXP-based Windows NT Server, you must install x86 printer drivers on the Alpha AXP-based print server.
The Windows NT and Windows 95 print client first attempts to use a local printer driver. If none is available, the Windows NT print server downloads the printer driver to the client computer's hard drive. The print client then uses its copy to create the print job.
In previous versions of Windows NT, printer drivers ran in user mode. With Windows NT 4.0, printer drivers run in kernel mode, thus reducing memory requirements and improving performance. For more information about user and kernel modes, see Chapter 5, "Windows NT Workstation Architecture."
Note Print clients running Windows NT 4.0 won't be able to use printer drivers downloaded from a print server running an earlier version of Windows NT. You'll need to make sure that the client computer has the 4.0 printer drivers, or better yet, use Windows NT 4.0 on your print servers. A print server running Windows NT 4.0 can supply earlier version printer drivers to downlevel print clients, if necessary.
Platform-specific printer drivers are available with Windows NT 4.0 Workstation for the following:
Print devices can be classified as either raster, PostScript, or plotter. To support these three classes of print devices, Windows NT provides the following generic printer drivers::
Universal Printer Driver
The Universal printer driver (Unidriver) is sometimes referred to as the raster driver because it supports raster graphics printing. The Unidriver can carry out requests on most types of printers. Each print device vendor provides a device-specific minidriver (called a characterization file) that works with the Unidriver to communicate with its print devices.
This driver includes support for 24-bit color, scaleable TrueType fonts, device fonts, compression-run length encoding (RLE), and Tag Image File Format (TIFF) version 4.0. It also includes mechanisms that provide for smaller, more efficient bitmaps. These mechanisms include ignoring whitespace and supporting rules. (Hewlett-Packard LaserJet and compatible print devices use rules to print repeating elements on a page—such as bullets in a list—by repeating the information from a single bit of source code.)
The Universal printer driver consists of the following component files:
The Windows NT Universal driver is a generic, text only (TTY) driver. It prints only text, and it prints it in the native font of the print device, regardless of any formatting in the original document.
PostScript Printer Driver
The Windows NT PostScript driver uses Adobe version 4.2-compatible PostScript printer description (.ppd) files. (Windows NT does not use the .wpd or .mpd files used by Windows 3.1). This driver supports key features, including binary transfer compression from Level II, resolution, and paper source.
The component files of the Windows NT PostScript printer driver are as follows:
HP-GL/2 Plotter Printer Driver
The Windows NT plotter driver supports a variety of plotters that use the HP-GL/2 language, but does not support HP-GL. The output from the Windows NT plotter driver requires a plotting device that can process all of the enhancements built into the HP-GL/2 language.
The Windows NT plotter driver consists of the following component files:
With Windows NT 4.0 you can establish printers with the Add Printer wizard or by using Point and Print.
Windows NT 4.0 provides the Printers folder to manage printing. Within it, the Add Printer wizard simplifies the task of establishing printers. You can open the Printers folder in the following ways:
To establish a printer with the Add Printer wizard
To establish a printer using Point and Print
Creating vs. Connecting to a Printer
The method used to establish a printer on a client computer dictates the configuration of the client computer in relation to the printer. The following table details the various methods.
Notice that only Windows NT and Windows 95 client computers can actually "connect to" a network printer served by a Windows NT print server. When a Windows NT or Windows 95 print client initiates a print request, the required printer driver is downloaded from the Windows NT print server if it is not already on the client's hard disk. All other client computers must "create" the printer—that is, they must install the printer driver directly on their hard disks, specify a port, name the printer, and so on.
Windows NT and Windows 95 print clients can also create a remote printer served by a Windows NT print server. Each method has advantages and disadvantages. Connecting to a remote printer is easier and faster than creating one. If the Windows NT client has connected to a printer, the print job doesn't spool on the client machine, so no spool options are available. (Windows 95 clients always spool locally and again remotely.) The "connected" client also cannot queue print jobs locally. Creating a printer gives the user more control, but that control is not always needed.
Specifying Virtual Printer Memory
You can change the amount of virtual memory that your PostScript printer has available for storing fonts. The PostScript driver uses a default setting recommended by the printer manufacturer for virtual memory.
To determine the right value, copy the Testps.txt file (supplied with the Windows NT Resource Kit) to the printer, and use the recommended virtual memory value printed on the resulting page.
To change your PostScript printer's virtual memory
Print clients, whether local (on the print server) or remote (on the network) send print jobs to a Windows NT print server. The print server services receive print jobs from remote clients as input/output (IO) requests that must be directed to the appropriate system process.
This chapter focuses on printing locally on the Windows NT Workstation and from Windows NT network clients. But, it also includes information about other network clients.
The following can all be print clients:
Windows print clients receive printer alerts confirming successful prints or indicating errors. If a client doesn't want to receive printer alerts, you can disable them by adding the following entry to the [Network] section of the System.ini file:
Note Disabling WinPopup does not disable printer alerts.
Windows NT Local Client
Windows-based applications and MS-DOS-based applications print in different ways and follow different rules. Windows-based applications send print jobs to printers added in the Printers folder. They typically use the printer drivers associated with those printers. However, some high-end desktop publishing or CAD applications have their own internal program copy of printer drivers.
In contrast, MS-DOS-based applications are unaware of the printers added in the Printers folder. They print to ports instead of to printers. This can cause problems. Whereas you could add several dozen printers in the Printers folder, most MS-DOS-based applications are limited to ports like LPT1–LPT3 and COM1–COM2. Windows NT accommodates MS-DOS-based applications in the following ways:
Assume you are interactively logged on to a print server, and that there are two printers in the Printers folder and two print devices. The server is named \\PSERVER1, the printer named HPV prints to an LPT2 port supplied by a separate IO card, and the printer named HPIIISI prints to the FILE port. Both HPV and HPIIISI are shared on PSERVER1 over the network. There are print devices connected to both LPT1 and LPT2. You open a command prompt and type the following command:
NET USE LPT3: \\PSERVER1\HPIIISI.
When you copy a file to each of LPT1, LPT2, and LPT3, the following results:
COPY TEST.TXT LPT1:
NTVDM checks with the redirector and finds that the redirector is not managing LPT1. It checks with the spooler and finds that neither of the defined printers prints to LPT1, so the job goes to the parallel port device driver.
COPY TEST.TXT LPT2:
NTVDM checks with the redirector and finds that the redirector is not managing LPT2. It finds that the printer HPV is printing to LPT2. NTVDM submits the job to HPV and that printer's spooling options take effect as the job is printed on LPT2.
COPY TEST.TXT LPT3:
NTVDM checks with the redirector and finds that the redirector is managing LPT3, so the redirector takes control. The redirector is set so that data sent to LPT3 is actually sent to the print share \\PSERVER1\HPIIISI. It sends the job to that share and once it arrives, HPIIISI's spooling options take effect. Although you usually use the net use command to assign a local port to a remote shared resource, it is perfectly legal to assign a local port to a local shared resource. This is often useful in testing and troubleshooting.
32-Bit Windows Network Clients
Windows NT and Windows 95 network clients can send print jobs using any of the following network protocols:
Windows NT 4.0 print clients now use enhanced metafile (EMF) data type instead of RAW. EMF allows the print job to be spooled to the server and rendered at the server into the appropriate print format. Remote rendering significantly speeds up the client computer's return to task.
Windows NT and Windows 95 network clients need not worry about printer drivers, because if the client doesn't have a needed driver it is automatically installed on the client's hard disk from the Windows NT 4.0 server when the client begins its print operation. If, however, the client computer is running Windows NT 4.0 and the server is running an earlier version, the printer drivers won't work. A Windows NT 4.0 print server can supply earlier version of printer drivers where necessary, but a Windows NT 4.0 client cannot use earlier versions of printer driver.
Windows 95 print jobs always spool EMF locally and playback locally to generate RAW data type before being sent to the print server. The print server spools them again.
The Windows NT print server receives print jobs from Windows 95 clients through the Windows NT Server service.
16-Bit Windows Network Clients
There is little difference between the different versions of the 16-bit Windows platforms. They all support printing from MS-DOS-based applications and from Windows-based applications by using the 16-bit printer driver installed on the computer. They typically send jobs to a Windows NT print server by using one of the following MS Network client redirectors:
The MS-Network redirectors send jobs by using the following protocols:
The Windows NT print server receives the job through the Windows NT Server service, which typically does not alter the print job. 16-bit Windows clients might also run third-party software for sending jobs to other print servers, such as LPR software for sending print jobs to UNIX print servers. This software is often able to send jobs to Windows NT as well.
Network Printing using Windows NT Workstation
There are essentially two ways to implement printing using Windows NT Workstation as the print server:
With Workgroup printing, the assumption is that the printer or printers are connected directly to the network, and that each user on the LAN creates the printer on his or her own computer and does not share it. Each user then sets his or her own printer driver settings and each computer must have the printer driver installed.
The disadvantage to this configuration is that you can't be sure that, for example, the paper tray you've designated as letter-sized actually contains letter-sized paper unless you physically go check it right before you print. Someone may have designated that tray as legal-sized paper and recently replaced the letter-sized cartridge with a legal-sized cartridge.
Each computer also has its own printer queue displaying only those print jobs sent from that computer. This is a disadvantage for determining where your print job is in relation to all the print jobs (including those from other computers), and gives the user no feedback about when a particular print job might actually print.
Another disadvantage to this setup is that errors (such as paper jams or no paper in the tray) appear only on the queue for the current print job. No other computer gets the error message. If the user at the computer getting the error message has left for lunch, printing could be held up for some time.
The second way to set up printing is to have one Windows NT Workstation function as print server. One computer in the LAN creates the printer and shares it with other computers.
Windows NT Workstation can support a small (maximum 10 connections) local area network (LAN) for printing. Because it is not designed to provide server functions, Windows NT Workstation has the following limitations that you need to understand in order to get satisfactory network printing performance.
In this scenario, printer driver settings are controlled by the print server computer. A single queue appears on every computer connected to the printer, letting each user see where his or her print job is in relation to others waiting to print. Error messages, therefore, appear on everyone's computer, so that anyone can know to refill the paper tray, clear the paper jam, or plug the printer back in. This method also allows you to have a single administrative log if you audit your printing events.
Print Server Services
Print server services are the software on the Windows NT print server that receive print jobs from specific types of network clients, determine whether the spooler should alter them, and then send them to the spooler by calling the spooler application program interfaces (API).
Each print server service uses different programmatic logic and makes different assumptions about print jobs from its supported print clients. These differences are detailed in the sections describing each service.
Windows NT Workstation provides the following print server services:
Client applications on the Windows NT Workstation print server itself use these additional software modules:
The following table lists each print server service and the type of print client processed by the service.
Windows NT Server Service
The Windows NT Server service receives jobs from applications and computers that are using the MS Network client and NetBIOS redirectors. This includes print clients using any of the following:
The Windows NT Server service does not set the data-type value when it submits the print job to the spooler. Instead, the spooler uses the default data type specified in the Print Processor dialog box on the print server. You can change the default data type. For more information, see "Data Types" earlier in this chapter.
Note If you select EMFor PSCRIPT1, the print spooler ignores this data and, instead uses the RAW data type to process print jobs. Detailed information on print spooler processing of data types is provided later in this chapter in the "Print Processors" section.
TCP/IP Print Service (LPD)
The TCP/IP Print service is generally referred to as LPD, which stands for line printer daemon (or "service"). LPD receives print jobs from line printer remote (LPR) clients. LPR clients are often on UNIX systems, but LPR software exists for most operating systems, including Windows NT.
LPR is one of the network protocols in the TCP/IP protocol suite. It was originally developed as a standard for transmitting print jobs between computers running Berkeley UNIX. The LPR standard is published as Request For Comment (RFC) 1179. Previous versions of Windows NT supported TCP/IP printing as documented in RFC 1179, which describes an existing print server protocol widely used on the Internet for communicating between line printer daemons but does not specify an Internet standard. Different implementations support different options.
Windows NT 4.0 has added enhancements to support the most popular and requested options. Windows NT now supports multiple data files per control file, and when used in "print through" mode as an intermediate spooler, it correctly passes the hostname parameter through the Windows printing subsystem. Windows NT 3.5x sent all TCP/IP print jobs from Windows NT computers from TCP ports 721 through 731. If enough jobs were sent in quick succession the ports could become a bottleneck causing a delay. For Windows NT 4.0 LPR print jobs are sourced from any available reserved port between 512 and 1023.
The LPR protocol does not pass detailed error status information back to the LPR client. If anything goes wrong, from severe problems (such as the server being too busy to process requests) to print-device problems (such as running out of paper), the LPR protocol reports the same error condition.
LPD receives jobs from LPR clients and submits them to the spooler. LPR clients always send a "control file" (actually, a data structure within the print job) containing administrative information with each print job. LPD assigns a data type based on the control commands in that control file.
If the client sends the f, o, or p control command, the LPD assigns the TEXT data type to the print job—which tells the spooler to edit the job to make sure it prints. If the client sends the l control command, the LPD assigns the RAW data type to the print job—which tells the spooler the print job needs no editing to print correctly. For more detail about data types, see "Data Types" earlier in this chapter.
Control commands are documented in the LPR specification, Request For Comment (RFC) 1179, sections 7.17 through 7.29. For detailed information about RFC 1179, refer to the Windows NT Knowledge Base article, "Text of RFC1179 Standard for Windows NT TCP/IP Printing," reference number 124734.
Note Notice that all the control commands defined in RFC 1179 are case sensitive. Notice also that many printer languages, including PCL, rely heavily on the ESC control character, which the f control command causes to be filtered from the print job. Do not use the f control command when sending print jobs that contain printer commands.
Because LPD assigns a data type explicitly, the default data type found in the Print Processor dialog box has no effect on print jobs received by LPD. To change the behavior of LPD, you must reconfigure the LPR client application to send a different control command with the print job. To reconfigure a LPR client application, consult the documentation for the application.
Windows NT Virtual DOS Machine (NTVDM)
MS-DOS-based applications run in a special Win32-based component referred to as a Windows NT virtual DOS machine (NTVDM). The NTVDM component translates MS-DOS operating system calls into calls used by the WIN32 subsystem.
If you print from a locally-run MS-DOS-based application or from a Windows NT command-line utility that sends data to a printer port, NTVDM receives the job. What happens next depends on whether the Windows NT redirector or the spooler manages the port:
For example, suppose one printer prints to COM1, and none of the printers print to LPT1 (but a print device is connected to LPT1). Also, suppose that you issue a net use command to redirect output from LPT2 to a network print share. If an MS-DOS-based application prints to LPT2, the job is sent to the network print share. If the application prints to COM1, NTVDM submits the job to the printer that prints to COM1, and that printer's default data type is used. If the application prints to LPT1, NTVDM submits the job directly to the parallel port device driver, and no print job alteration occurs.
Windows NT Graphical Device Interface (GDI32) for 16-Bit Applications
On a Windows NT computer, Windows 3.x-based (16 bit) applications are supported by a Graphical Device Interface 32 (GDI32) engine. The GDI32 engine translates print and display application programming interface (API) calls to 32-bit WIN32 services.
The GDI32 graphics engine (Gdi32.dll) is the printing component that provides What You See Is What You Get (WYSIWYG) support across devices. The graphics engine communicates with Windows-based applications through the Windows Graphics Device Interface (GDI) and with printer drivers through the Device Driver Interface (DDI).
When a Windows-based application creates a print job, it describes the output it wants in a series of GDI commands. The GDI32 graphics engine is the component that translates these GDI commands into the DDI commands understood by components such as printer drivers and print processors.
The GDI32 graphics engine queries the printer driver to identify the capabilities of the print device, including supported fonts. Using this information, the GDI32 graphics engine uses other DDI commands to specify the positioning of each character in the document by the print device. The GDI32 graphics engine also uses DDI commands to define how the print device should draw and fill graphics and how to manipulate and print bitmaps.
The GDI32 graphics engine provides services to the printer driver, including compatibility with the environment subsystem (for example, MS-DOS or OS/2) and performance optimization, caching, client-server communications, and ANSI-to-Unicode conversion.
The GDI32 graphics engine calls the printer driver and provides information about the type of print device needed and the data type used. In response, the printer driver provides the graphics engine with the fully qualified path name for the print device and printer-setting information. This information is passed to the spooler.
The preceding sections described network print clients, print server services, print jobs, data types, and print devices. These are entities at the beginning and end of the printing process. The following sections describe the Windows NT print spooler components and the processing that takes place on a Windows NT print server after the print job is created and before the print job reaches the print device.
The following figure shows the main spooler components used to process jobs on a Windows NT print server. Each component uses the services of the component directly below it.
Figure 7.1 Print Spooler Components
As shown in the figure, the components below the client and above the print device are collectively called the spooler. The spooler is a series of 32-bit virtual device drivers and DLLs consolidated into a single architecture. It provides smooth background printing by using background thread processing. This means that the spooler passes data to the printer only when the printer is ready to receive more information. In Windows NT, the spooler components are implemented as a service that you can stop and restart from the Services icon on the Control Panel or from the command line by using the net stop spooler and net start spooler commands.
Important If you stop the spooler service, you will not be able to print until you start it again.
The spooler components reside on both the Windows NT print server and on the Windows NT client computer. Client computers running a different operating system might have different components, and they might interact differently with the Windows NT print server's spooler components. The following table lists the components of the Windows NT spooler:
Each spooler component is described in more detail in the following sections.
When a Windows NT application has a print job it wants to send to the printer, it communicates with the client side of the spooler (Winspool.drv). This file makes an RPC to the server side of the spooler (Spoolss.exe), which makes a direct API call to the router (Spoolss.dll—which is also on the server side of the spooler).
The router passes control of the print job to the appropriate print provider. In the case of local printing, the local print provider takes the print job. If the print job is going to a server on the network, the router passes the print job to the appropriate remote print provider—the Windows remote print provider or the Novell NetWare print provider.
Do not confuse the software router component of the Windows NT spooler with the physical hardware router used in networks.
Remote Print Providers
When a client computer connects to a remote printer and sends a print job to it, the router polls each of the remote print providers on the client computer. The router passes control of the print job to the first remote print provider that recognizes the printer name.
Windows NT supplies the following remote print providers:
Note Neither of these remote print providers performs spooling.
Windows Network Print Provider
If the local copy of the Windows network print provider, Win32spl.dll, recognizes the printer name, it performs additional processing based on the type of print server to which the job is going. If the print server is running Windows NT, Win32spl.dll makes remote procedure calls to the router (Spoolss.dll) on the print server. The router receives the print job over the network and passes it to the local print provider as if one of its own local clients had submitted it.
If the remote print server is a downlevel server, Win32spl.dll sends a message to the Windows NT NetBIOS redirector. The redirector forwards the job over the network to the downlevel server.
The functions provided by the Windows network print provider are illustrated in the following figure.
Figure 7.2 The Windows Network Print Provider (Win32spl.dll)
Novell NetWare Remote Print Provider
If the NetWare print provider (Nwprovau.dll) recognizes the printer name when polled by the router, it takes control of the print job. The NetWare print provider sends a message to the NetWare workstation service (Nwwks.dll), which in turn passes control to the NetWare redirector. The NetWare redirector transmits the print job over the network to the NetWare print server.
Note To send print jobs over Windows NT to a NetWare print server, you must install Gateway Services for NetWare. To receive print jobs from NetWare print clients, you must install File and Print Services for NetWare.
Figure 7.3 The NetWare Print Provider (Nwprovau.dll)
Local Print Provider (Localspl.dll)
The local print provider writes the print job contents to a spool (.spl) file and tracks administrative information (such as user name, document name, and data type) in a shadow (.shd) file. By default, both files are written to %systemroot%\system32\spool\printers.
If, however, the hard drive partition containing Windows NT Server doesn't have sufficient disk space to accommodate the spool files, you can change the location of spool files by changing the server properties.
To change the location of spool files
Note You must create a directory for the new spool file location. If you attempt to spool directly to the root (C:\ or D:\, for example) the spool file will revert to the default spool directory.
Spooling a print job to a file protects the print job by saving it on disk. Should the print server suffer a power failure or other serious event before printing all jobs in the queue, the spool and shadow files on the server's hard disk preserve each job and prevent any loss of data once processing resumes.
By default, spool and shadow files are deleted after the job prints. However, you can enable spooler event logging to get valuable information about printer traffic, hard disk space, and other printing maintenance issues.
To enable spooler event logging
Next, LOCALSPL polls the installed print processors (such as Winprint.dll and Sfmpsprt.dll) to see if one of them recognizes the job's data type set. If the data type is not set, the Winprint.dll print processor receives the job and uses the default data-type set Print Processor dialog box on the print server.
You can set a new default location or override the default location on a printer-by-printer basis by manually editing the Registry. However, before doing so, read the "Spooler File Security" section later in this chapter.
Enhanced Metafile (EMF) Spool Files
Enhanced metafiles (EMF) are one type of spool file used by the default Windows NT print spooler. EMF spool files are used to reduce the time between the initiation of a print request and when control is returned back to the operating system. This is done by storing only the GDI function calls that produce the graphic object the application wants printed. The much more time-consuming execution of function calls can then be carried out later, in the background, when the spool file is played back.
The way EMF spool files are encoded also provides the advantage of printer device-independence. In other words, a picture measuring 2 inches by 4 inches on a VGA display and stored in an EMF maintains those original dimensions whether it is printed on a 300 dpi laser printer or on a 75 dpi dot matrix printer.
RAW Spool Files
If the print job's data type is RAW, the spool file's data type is RAW. These files are device-dependent. The spooled data is destined and formatted for a particular device and does not need to be printable on a different device. An example of a RAW spool file is an encapsulated PostScript (EPS) file, which is formatted to be understood by the PostScript printer for which it is destined, but which is just RAW data to the Windows NT spooler.
The print processor is the component that make necessary alterations to print jobs, based on the data type of the print job. The print processor (Winprint.dll) works in conjunction with a printer driver to despool the spooled print jobs during print spool file playback.
A print device vendor might develop a custom print processors if
Additional print processors may be supplied by third-party software vendors to support custom data types.
Windows NT 4.0 supports two kinds of print monitors: language monitors and port monitors.
A language monitor is necessary to support bi-directional print devices. A bi-directional print device supports two-way communication between the print device and the spooler running on its print server. The language monitor allows the spooler to configure and monitor the status of a bi-directional printer. A language monitor can also add data (such as printer control information) to the print stream. When you create a printer, you install a printer driver. If a language monitor is associated with that printer driver, all data that flows from the printer driver to the print device goes through the language monitor before it goes through the port monitor and out to the printer.
Two-way communication between computer and print device allows a system administrator to configure the printer and to monitor printer status. The spooler running on the computer can request configuration and status information from the printer, and the printer can send unsolicited status information to the computer (such as the fact that the paper tray is empty). A common language is necessary for the two devices to understand each other.
The language monitor supplied with Windows NT 4.0 uses Printer Job Language. If a print-device vendor uses a printer language other than PJL, that vendor can develop a language monitor for it. A vendor might also develop a language monitor to add data, such as printer-specific control information, to the print stream going to a single directional printer.
Port monitors control the I/O port to which the physical print device is connected. The local print monitor executable (Localmon.dll) supplied by Microsoft controls parallel and serial I/O ports that may have a print device connected to them. Print devices connected to different types of I/O ports such as SCSI or Ethernet ports on a network card or adapter, are controlled by vendor-developed port monitors.
The print monitors supplied with Windows NT are described in the following sections.
The Ports tab of the Printer Properties dialog box lists the default Windows NT ports.
By default, the list includes only standard ports controlled by the local print monitor, Localmon.dll. When you want to print over other communications channels (to a network-attached printer, for example), you must create a new port.
To create a new port
Print monitors often depend on other software components and appear in this list only when you have installed the components they require. For example, the Hewlett-Packard Network print monitor transmits print jobs by using the DLC network protocol. This monitor appears in the list only if you have installed the DLC protocol.
Each monitor displays its own user interface, which you use to create a new port and configure a printer to use it. To reconfigure the new port (if the monitor allows reconfiguration), click the Configure Port button on the Ports tab of the Printer Properties dialog box.
When you read about each print monitor in the following sections, remember that each is associated with a data communications channel, not with the print device at the other end of that channel. In most cases, the port monitor is unaware of the make or model of the print device it is communicating with, nor does it need this information. Also, although different port monitors might use the same network protocol, this does not make them interchangeable. For example, both the Digital Network Port print monitor and the LPR Port print monitor use the TCP/IP protocol, but they send data over that protocol in very different ways.
Local Print Monitor (Localmon.dll)
The local print monitor, Localmon.dll, sends print jobs to local devices. These include familiar ports like LPT1 and COM1. Use of the less familiar FILE and Other ports are described below.
The FILE port appears in the default port list on the Ports tab of the Printer Properties dialog box. When you send jobs to a printer that uses this port, the local print monitor prompts you for the name of a file in which the print job should be stored.
If you select Other from the list of ports in the Print To box on the Printer Properties dialog box, and select the Local Port option, the local print monitor prompts you to enter a port name. Some possibilities include:
Hewlett-Packard Network Port Print Monitor (Hpmon.dll)
The Hewlett-Packard Network print monitor, Hpmon.dll, sends print jobs to HP JetDirect adapters. This includes both the network adapters commonly installed in print devices (such as the LaserJet 4 Si) and the JetDirect device (which connects a parallel print device to the network).
Although many JetDirect devices can communicate over several different network protocols, including DLC, IPX, TCP/IP, and AppleTalk, Hpmon.dll is specific to DLC; you must load the DLC protocol to use this print monitor.
The DLC protocol is bridgeable, but not routable. This means that if a Windows NT print server is on one physical subnet and a JetDirect device is on another physical subnet, the server can send jobs to the JetDirect if the two subnets are joined by a bridge but cannot send jobs if the two subnets are joined by a router.
The DLC protocol can be bound to multiple network adapters, but the HP print monitor software can only manage printers over one network adapter, and it must be either adapter 0 or adapter 1. If your Windows NT computer has multiple network adapters, make sure all the HP JetDirect-equipped printers are on the same physical subnet.
When you install, reinstall, or upgrade Windows NT, it assigns a number to each network adapter in your computer. The adapter with the lowest I/O base address is assigned the number 0; the adapter with the next lowest I/O base address is assigned the number 1, and so on. If you later add another network adapter, it is assigned the next unused number, regardless of its I/O base address. Later, if you upgrade or reinstall Windows NT, each adapter is again assigned a number based on its I/O base address. If the third adapter has a lower I/O base address than either of the other two, then the numbering changes. In this case, HPMON looks for JetDirect cards through the wrong network adapter on the server.
To correct adapter numbering after an upgrade
You can configure ports managed by Hpmon.dll as either job-based or continuous connection. The setting affects all ports at once:
Line Printer Port Monitor (Lprmon.dll/Lpr.exe)
Windows NT supplies a command line utility (Lpr.exe) and the LPR Port print monitor (Lprmon.dll). Both act as clients sending print jobs to an LPD service running on another computer. As mentioned previously, Windows NT also supplies an LPD service, the TCP/IP Print service, which receives print jobs sent by LPR clients, including UNIX computers and other Windows NT computers using the TCP/IP protocol.
To send print jobs, the LPR clients needs the network address of the LPD print server and the name that the LPD service associates with its print device. LPR sends print jobs to LPD along with instruction on how to process the job and the name of the print device.
When you add an LPR port while connecting to the LPR print server, you'll be asked in a dialog box to supply information identifying the print server (host) and the name of the printer. You can supply either the IP address or the host name of the server. The server can be one of the following:
For example, let's say you're connecting to a printer named LABLASER on a UNIX computer whose IP address is 18.104.22.168, and whose name (defined in the hosts file on your Windows NT computer) is UNIXBOX. You can enter either "UNIXBOX" or "22.214.171.124" (without the quotation marks) in the Name Or Address Of Host Providing LPD box. You would enter LABLASER in the Name Of Printer On That Machine box.
To obtain the IP address of a network adapter, check the adapter's documentation. Some adapters provide a character-based application that you can access either by network connection or by directly connecting to the adapter by means of a serial-to-serial port cable.
If the server is a UNIX computer, and you don't know a valid name for the printer, you can often find it by looking at the /etc/printcap file on the UNIX computer. Each entry corresponds to a print queue ("printer" in Windows NT terminology) on the UNIX computer. Fields in these entries are separated by ":" characters, and for readability an entry can be broken over several lines by ending a line with a "\" character and beginning the next line with a space or tab character. The first field of each entry lists valid names for the queue, separated by "|" characters.
Continuing the LABLASER example, we might find entries like the following in the printcap file on the computer named UNIXBOX:
lp|lablaser|The_Lab_Printer:\ :lp=/dev/ttya:br#9600:\ :lf=/usr/spool/lpd/lablaser-err:\ :sd=/usr/spool/lpd/lablaser:
The first line in this example defines a print queue with three valid names: lp, lablaser, and The_Lab_Printer. You can use any of these names in the second field of the LPR Port dialog box previously shown.
Note This example is provided for illustrative purposes only. The UNIX system documentation is your best source of detailed information on your system's printcap file. Also note that the term "queue" is the UNIX term. Its Windows NT equivalent is "printer."
When the LPR Port print monitor receives the LPD server's network address and the proper queue name, it can send print jobs and processing instructions.
The LPR Port print monitor sends the l command by default, whereas the command line Lpr.exe utility sends the f command by default. With the Lpr.exe utility, use the -o command if you want to override the default on a job-by-job basis. To change the default command for a particular printer controlled by the LPR Port print monitor, you must modify a Registry parameter. Use the Registry Editor (Regedt32.exe) to find the following key:
HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Control \Print \Monitors \LPRPort \Ports<portname>\<IP Address or Host name>:<printer name>
In this key, add a value named PrintSwitch with type REG_SZ, and enter the control command you want to use. For instance, enter the letter "f" (without the quotation marks) if you want to use the f command by default.
Some UNIX computers do not follow the control commands alone when deciding how to process a print job. For instance, if you send an ASCII text file with an l command (which tells the spooler not to alter the print job) to a PostScript printer, it does not print correctly. Consequently, many UNIX systems have added software that converts scans jobs that arrive with the l command. If the scanner finds PostScript commands, the job goes directly to the printer. If no PostScript is found, the added software adds the PostScript code so that the job prints correctly.
If you send PostScript jobs from a Windows NT computer using LPR, and the printer controlled by the UNIX server prints the PostScript code instead of interpreting it, the UNIX server might have a scanner that does not recognize the output from the Windows NT PostScript driver as valid PostScript code. If this happens, you might need to reconfigure Windows NT to use the o control command by default.
If the client sends the f, o, or p control command, the Windows NT TCP/IP Print service assigns the TEXT data type to the print job—which tells the spooler to edit the job to make sure it prints. If the client sends the l control command, the Windows NT TCP/IP Print service assigns the RAW data type to the print job—which tells the spooler the print job needs no editing to print correctly. For more detail about data types, see "Data Types" earlier in this chapter.
Control commands are documented in the LPR specification, Request For Comment (RFC)1179, sections 7.17 through 7.29. For detailed information about RFC 1179, refer to the Windows NT Knowledge Base article, "Text of RFC 1179 Standard for Windows NT TCP/IP Printing," reference number 124734.
LPD-compliant print devices must supply one or more names for each of their print queues, even though these devices often have only one possible destination for the print jobs they receive. Each print-device manufacturer chooses naming conventions independently. Some, like the HP JetDirect adapter, accept any string as a legal print queue name. In comparison, the Emulex NetJet adapter accepts only two strings, and these are case sensitive, and default to TEXT and PASSTHRU. These strings are configurable. To find the names supported by any specific adapter, check its documentation, or contact the vendor's technical support group.
Remember that the local print provider spools print jobs, and that it despools them to the print monitors. In Windows NT, after LPRMON receives a job from the local print provider, it spools it a second time as a temporary file in the SYSTEM32 subdirectory. LPR must include an accurate byte count in the control file, and it cannot get that byte count from the local print provider. Instead, it respools the data to a temp file, finds the size of that temp file, and sends that size in the control file to the LPD server.
The most common problem people encounter when printing from UNIX systems to a Windows NT print server is that their print jobs are processed as TEXT data type instead of RAW data type, as they would be on a UNIX system. This happens because the UNIX systems almost always send the f control command, expecting that the control command isn't too important, because the TCP/IP (LPD) server parses the job to identify what data type to use and how to alter the job. However, Windows NT relies on the control command to determine the data type. As a result, the LPD service on Windows NT assigns the TEXT data type to most jobs.
To correct this problem, reconfigure the LPR client to send the l control command so the LPD will assign the RAW data type.
Macintosh Port Monitor (Sfmmon.dll)
The Macintosh port monitor, Sfmmon.dll, transmits jobs over a network using the AppleTalk protocol to network-attached print devices, such as the Apple LaserWriter family. It also lets you send jobs to AppleTalk spoolers, regardless of the print device that the spooler is attached to.
This monitor is available on both Windows NT Workstation and Windows NT Server computers and enables any Windows NT–based computer to send local print jobs to AppleTalk print devices. However, only Windows NT Server has a Macintosh print server component, so only a Windows NT Server computer can receive print jobs from Macintosh clients.
Some print devices process non-PostScript print jobs incorrectly if they receive those jobs over AppleTalk. Also, some print devices process PostScript jobs incorrectly if those jobs contain binary data and arrive over any protocol other than AppleTalk. These problems result from restrictions in those print devices; they do not indicate that the Windows NT print server is transmitting the jobs incorrectly.
Digital Network Port Monitor (Decpsmon.dll)
The Digital Network Port print monitor, Decpsmon.dll, sends print jobs to Digital Equipment Corporation's Digital PrintServer print devices and to other Digital Equipment Corporation print devices (such as the DEClaser 5100 and the DECcolorwriter 1000).
Windows NT supplies the TCP/IP network protocol, but does not supply the DECnetprotocol. If you want to use DECnet, you must contact Digital Equipment Corporation to obtain it.
LexMark Mark VisionPrint Monitor (Lexmon.dll)
LexMark's Mark Vision print monitor (Lexmon.dll) sends print jobs to LexMark MarkNet print devices (such as the MarkNetXL) and to network adapters (such as the MarkNetXLe). This print monitor uses any of the following protocols:
NetWare Print Monitor (Nwmon.dll)
NetWare's print monitor (Nwmon.dll) sends print jobs to Pserver print devices. Pserver is a print-device standard developed by Novell.
In most situations, the print server drives the trnsport process of delivering the print job over the port. In the case of a Pserver print device, Nwmon.dll manages the communication between the device and the server. The Pserver "grabs" the print job from a passive print queue.
PJL Monitor (Pjlmon.dll)
The PJL Language Monitor, which Windows NT 4.0 supplies, "speaks" printer job language (PJL). Any bi-directional print device that uses PJL can use PJL Language Monitor. For example, PJL is the language that implements all the bi-directional communication between an HP LaserJet 5Si (a bi-directional print device) and its print server.
Bi-directional communication allows applications to query the print device directly to determine its capabilities. It also provides the benefit of configuring printer driver settings on the server without user intervention. The printer driver can automatically determine how much memory the printer has, what printer fonts are available, and so on.
Bi-directional print devices can send unsolicited messages to Windows NT and to applications. For example, the print device might send an "out of paper" or "printer offline" message. Bi-directional communication enables much more detailed status reporting on a wider variety of information, such as low toner, paper jams, maintenance needs, and so on.
To take advantage of bi-directional printing, you must have the following:
Printer properties include everything about a printer from what port you use to what security features you want to implement.
To set or change printer properties
Separator Page Files
Separator pages—also called burst pages, header pages, or banner pages—print before each print job. They typically identify the computer that created the job, the time it was created, and so on. The local print provider contains an interpreter that reads commands from a separator page file to produce separator pages.
By default, separator page files are stored in the %systemroot%\system32 directory. To use a separator page file, click the Separator Page button on the General tab of the printer's Printer Properties sheet. Either type the name of the Separator Page file, or browse through the directories and select a file. Windows NT provides three separator page files; you can use them as is, or modify them to create your own custom separator page files.
The following table lists the separator page files included with Windows NT.
To create a custom separator page file, copy and rename one of the supplied files, and then edit it. The following table provides the escape codes you can use. The separator file interpreter replaces these escape codes with appropriate data, which is sent to the printer.
You can limit the access that users have to your network printers and spool file directory by using Windows NT security. You can provide additional security by forwarding print jobs to other print servers.
To specify security attributes on a printer-by-printer basis, use the Security tab in the Printer Properties dialog box. The most efficient way to establish security attributes is to assign permission levels to different user groups. For example, you could give all nonadministrative users in a department the Print level of permission and all managers Full Control permission.
The following table summarizes printer security permissions.
The installation-default printer permissions are different for Windows NT Server and Windows NT Workstation computers. By default, the following print permissions are assigned on a Windows NT Workstation computer:
To change security permissions
Spool File Security
To implement spool file security, change the default spool directory to an NTFS partition and directory where write permission is limited on a user-by-user basis.
When a print job prints locally, the local print provider spools the job to disk during processing. By default, the Everyone group has Change permission in the default spool directory. This allows all user print jobs write access to the default spooler directory.
A print job that cannot be spooled to disk during processing does not print. If the spool directory location is changed, all users who need to print must have Change permission for the new spool directory.
As described in the section "Local Print Provider," the spool file (SPL_) and the shadow file (SHD) are written to the default spooler directory: %Winnt\System32\Spool\Printers
For instructions on changing the default spool file directory, see "Local Print Provider" ealier in this chapter.
To override the default location for one specific printer
Note You must create a directory for the new spool file location. If you attempt to spool directly to the root (C:\ or D:\, for example) the spool file will revert to the default spool directory.
The change in the Registry takes effect after you stop and restart the Spooler service.
Most printing-related Registry settings reside in the following subkey
HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Control \Print
An administrator can use the Registry Editor to assign read-only access to these subkeys. Users with read-only access cannot add or configure printers, because the read-only access does not allow changes of these subkeys.
Windows-based applications also use the following subkey in the Registry to find information about available printers.
HKEY_CURRENT_USER \Software \Microsoft \WindowsNT CurrentVersion\PrinterPorts
Users with read-only access to this subkey cannot add new printers that are recognized by Windows-based applications.
To forward a print job to a different Windows NT print server, a Windows NT print server uses a null session. By default, the null session is disabled, preventing job forwarding. To enable job forwarding and null-session support, manually edit the following Registry subkey:
\HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services LanmanServer\Parameters
In this subkey is a value named NullSessionShares. Add a new line containing the share name for the printer. This change does not take effect until you stop and restart the Spooler service.
Troubleshooting Printing Problems
Troubleshooting Windows NT printing problems can be a challenge because of the number of variables involved in printing and the number of different clients and print devices that Windows NT supports.
Windows NT has a modular printing architecture, with a module for each major task (such as receiving jobs from network clients). By adding new modules you can easily add functionality (such as support for a new type of network client). This modularity gives Windows NT a great deal of flexibility, making it able to support a wide variety of client operating systems, applications, data objects, network configurations, spooling options, and print devices. That flexibility comes at a cost, however, because each additional configuration adds its own possible points of failure.
Successful troubleshooting depends on your ability to quickly rule in or rule out general categories of points of failure. The modularity makes this fairly easy: Network printing, for example, consists of seven processes that always occur in the same order. By testing one of the processes, you can determine whether the problem is occurring in that process, before it, or after it.
The following are the seven basic processes involved in a network printing job:
The basic strategy for troubleshooting printing problems is to use problem symptoms to identify the process, or processes, that are creating the problems. If you still cannot correct the problem after you've located it, your technical support engineer will be much better able to help you correct it if you have first isolated the process where the problem exists.
To troubleshoot printing problems
To help you implement this strategy, this section presents the seven basic printing processes and gives the following information about each process:
Printer Definition and Configuration
A print server administrator can use the Add Printer wizard to:
Both procedures install and configure a printer driver. Creating a printer gives more control over driver configuration than connecting to a printer, and the administrator can create new printer ports by entering values in the Print To field on the Printer Properties sheet. The administrator can also define form-to-tray mapping, security, and spooler options.
The problem is likely in this process if...
Client Computer Connects to a Shared Printer
A printer is established on a print client computer.
The problem is likely in this process if...
Client Application Creates a Print Job
A user on a client system runs an application that composes text and/or graphics to create a print job. The application may interact with a printer driver to create output in a printer language such as PCL, PostScript, or HP-GL/2.
The problem is likely in this process if...
If the problem persists when you send a simple textprint job from several clients' systems, the problem is likely caused by another printing process.
Client Sends Job to Spooler
The user on the client system sends the job over the network to the print server. The client system's application software or operating system sends the job to the client's transport protocol, to the network adapter, over the network hardware, to the transport software on the print server, and finally to the appropriate print server service on the print server. The print server service (Windows NT Server, Services for Macintosh, or TCP/IP Print) assigns a data type to the print job and submits the print job to the spooler, or leaves it blank.
The problem is likely in this process if the problem is limited to...
The problem is also likely in this process if...
Suspect a problem elsewhere if...
Print Server Spooler Processes Print Job
The spooler receives the job from the print server service. If the printer was established by selecting the Network Printer option in the Add printer wizard, the remote print provider sends the job to the print server. Otherwise, the job goes to the local print provider.
Unless otherwise configured, the local print provider spools the job to disk and checks the data type assigned by the print server service. The data type (for example, RAW or PSCRIPT1) determines which print processor receives the job. The data type also effects whether the print processor alters the job or not, and if so, how it alters the job. If the spooler is configured to append a separator file, it does so before sending the job to the print monitor for delivery to the print device.
The problem is likely in this process if...
Print Server Spooler Sends Job to Print Device
The print monitor receives the job and interacts with local hardware drivers and transport drivers to send the job to its destination. The components in this process are:
The problem is likely in this process if it is limited to...
The problem is also likely in this process if...
Print Device Interprets Job
The final processing at this point is completed by the print device. The print device receives the print job from a hardware port. The print device interpreter interprets the job and produces hardcopy output.
The problem is likely in this process if...
Questions and Answers
This section presents specific questions and answers about Server Printing.
Does the Windows NT print server support UNIX clients running LPSSCHED?
No, it does not support UNIX computers running LPSSCHED. UNIX client computers must have an LPD program installed when used with a Windows NT print server.
How can platform-specific printer drivers be installed for a print client on a hardware platform different than the Windows NT print server?
Microsoft places all new or updated printer drivers onto its electronic services for public download.
Also, a platform-specific printer driver is likely available on another computer in the network.
To install platform-specific printer drivers from another computer in the network
What kind of problems occur when a print job has been assigned an incorrect data type?
Typical problems that occur when there is some error in the data type assignment and consequent job alteration of a print job include the following:
How many printers can be supported by a Windows NT print server?
The limitation on the number of printers that can be attached to Windows NT print server is dependent on whether the print server is a Windows NT Workstation computer or a Windows NT Server computer. Windows NT Workstation and Windows NT Server have been optimized for different roles in the network:
Windows NT Workstation is limited to 10 connections from other computers and should be used as a print server in small-network situations.
Windows NT Server has been optimized as a print, file, and application server.