Troubleshooting Windows NT Print Server Alteration of Print Jobs

• Microsoft Network Client for MS-DOS, version 3.0
• Microsoft Windows for Workgroups version 3.11
• Microsoft LAN Manager for MS-DOS, version 2.2c
• Microsoft Windows NT operating system version 3.1
• Microsoft Windows NT Advanced Server version 3.1
• Microsoft Windows NT Workstation version 3.5, 3.51 and 4.0
• Microsoft Windows NT Server version 3.5, 3.51 and 4.0

SUMMARY

Windows NT print servers are able to alter client print jobs. The software responsible for altering client jobs rarely malfunctions, but sometimes alters jobs when you do not expect it to. This article describes how to troubleshoot such situations, explains how this behavior changes with different network clients, and details the "data type" concept that controls the spooler's alterations.

Troubleshooting: Windows NT Print Server Modifies Client Print Jobs

There are five common job alteration problems:

• LPR Client Print Jobs Include PCL or PostScript Code, Include Incorrectly Printed Extended Characters, or Print in the Print Device's Default Font.
• Last Page of a Microsoft Network-Based Client Print Job Does Not Print
• Extra Page Prints After a Microsoft Network-Based Client Print Job
• Microsoft Network-Based Client Print Jobs Include PCL or PostScript Code, Include Incorrectly Printed Extended Characters, or Print in the Print Device's Default Font
• PostScript Print Jobs Sent From Macintosh Clients Do Not Print in Color, Print at a Lower Resolution, or Fail

• Microsoft LAN Manager client software
• Microsoft Network Client for MS-DOS
• Windows for Workgroups
• Windows NT (when printing to a universal naming conversions (UNC) name

When you send a job from a line printer remote (LPR) client, one of the following happens:

• Printer-language code (Printer Control Language [PCL] or PostScript code) is printed.
• Extended characters in text print jobs print incorrectly.
• Text jobs print in the print device factory-default font, even if you change the print device default font.

To work around this problem, reconfigure the LPR client to send different commands so that Windows NT assigns the job the RAW datatype.

Last Page of a Microsoft Network-Based Client Print Job Does Not Print

When you send print jobs from a Microsoft network-based client to a PCL print device, and the last page of the job does not print until the next print job arrives, or until you manually force a form-feed.

This problem occurs when client applications do not append form-feed commands to their print jobs and the Print Manager default datatype is RAW.

To work around this problem, set the default datatype value to RAW [FF Auto] or [RAW FF Appended], or reconfigure the client application to append a form feed to print jobs.

Extra Page Prints After a Microsoft Network-Based Client for MS-DOS Print Job

When you send a print job from a computer running a Microsoft Network-Based Client to a PCL print device, and an extra page prints.

This problem occurs when client applications append form-feed characters to their print jobs and the Print Manager default datatype is RAW [FF Appended] or RAW [FF Auto]. Print jobs from Windows-based applications always appended with have form-feed characters; print jobs from MS-DOS-based applications often do not have form-feeds at the end.

To work around this problem:

• If all client print jobs sent to the print share already have form-feed commands, set the default datatype to RAW.
• If some client print jobs include form-feed commands but others do not, set the default datatype to RAW [FF Auto].
• Reconfigure the applications to prevent them from adding the form- feed command to print jobs.

When you send a job from a computer running a Microsoft Network-Based Client, one of the following happens:

• Printer-language code (Printer Control Language [PCL] or PostScript code) is printed.
• Extended characters in text print jobs print incorrectly.
• Text jobs print in the print device factory-default font, even if you change the print device default font.

To work around this problem, set the default datatype value to RAW.

PostScript Print Jobs Sent From Macintosh Clients Do Not Print in Color, Print at a Lower Resolution, or Fail

When you send a PostScript print job from a Macintosh client, one of the following happens:

• Color print jobs print in black and white.
• Right resolution print jobs print at 300 DPI.
• Although Level 1 PostScript print jobs print correctly, Level 2 PostScript print jobs fail.

To work around this problem:

• Run Print Manager and reconfigure the printer to use a PostScript printer driver.
• Send print jobs directly to the print device instead of sending them to the Windows NT print server.
• Purchase a third-party replacement for the Windows NT Services for Macintosh raster image processor (RIP).

Client Type Affects How Windows NT Print Servers Modify Client Print Jobs

When a client sends a print job to a Windows NT print server, a server service receives it and passes it to the Windows NT spooler service for processing. Different services receive and process the print job depending on the client used to sent the print job. For example, when you print from a Microsoft network client (such as Windows for Workgroups or Microsoft Network Client for MS-DOS, version 3.0), the Windows NT Server service receives the job and submits it to the spooler. When you print from an LPR client, the Windows NT LPD service receives the job and submits it to the spooler.

The service that submits the print job decides whether the spooler should alter the print job, how to alter the print job, and assigns the print job the corresponding datatype value. The service can also leave the datatype blank and let the spooler apply the default value. Each of the services supplied with Windows NT uses different logic to determine how the job should be altered. The sections below detail the logic for each of these clients, and describe how to change that logic.

Microsoft Network-Based Clients

The Server service receives jobs from Microsoft network-based clients. The Server service does not set the datatype when it submits the job to the spooler, so the spooler uses the datatype listed in the Print Manager default datatype.

To change the way the spooler alters jobs from Microsoft network-based clients, change the Default Datatype value:

1. Run Print Manager.

2. Select the printer you want to configure.

3. From the Printer menu, choose Properties.

4. Choose Details.

LPR Client

LPR Overview:

Although LPR clients are often UNIX-based, LPR software exists for most operating systems, including Windows NT. The Windows NT TCP/IP Print Server (LPD) receives jobs from LPR clients and submits them to the spooler. LPR clients always send a control file containing administrative information with each print job. The Windows NT LPD service assigns a datatype based on the control file commands. If the client sends the "f", "o", or "p" control command, LPD assigns the job the TEXT datatype. Otherwise, LPD assigns the print job the RAW datatype.

The control commands are documented in the LPR specification, RFC1179, in sections 7.17 through 7.29. (The text of RFC1179 is available in the Windows NT Knowledgebase.)

Because the LPD service assigns a datatype explicitly, the Print Manager default datatype has no effect on print jobs that arrive via LPD. To change the LPD service behavior, reconfigure the LPR client to send a different control command.

Configuring UNIX LPR Software:

Different UNIX LPR clients often have different configuration options. For example, to change the control command, you may need to change a value in a printcap file, change a model script, modify an LP or LPR command line, or change settings through a graphical interface.

Some UNIX LPR clients are not configurable. For example, the IBM AIX LPR client always sends the "f" control command.

Configuring Windows NT LPR Software:

There are two ways to send print jobs from Windows NT using LPR; each has a different default control command and different configuration procedure.

The Windows NT Print Manager LPR Port monitor software sends the "l" control command by default (because most jobs sent through Print Manager come from Windows-based applications). Because Windows-based applications use a Windows NT printer driver to fully render the print job, the "l" control command is used to indicate that the LPD server should pass the job through unaltered.

You can configure the control command by editing the registry:

WARNING: Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk.

1. Run Registry Editor (REGEDT32.EXE).

2. From the HKEY_LOCAL_MACHINE subtree, go to the following key:

         \System\CurrentControlSet\Control\Print\Monitors\LPR Port
           \Ports\<portname>
   
   

3. From the Edit menu, choose Add Value.

4. Add the following:

         Value Name: PrintSwitch
         Date Type: REG_SZ
         String: <the single character you to be sent as a control command>
   

5. Choose OK and quit Registry Editor.

The "-o" switch exists in both Windows NT 3.5 and 3.51, but was not properly documented in 3.5. Add the control command that you want to send to the end of the "-o" switch. For example, to send the "l" control command instead of the default "f" control command, use:

   LPR -S <servername> -P <printername> -ol <filename>

For more information about specific data types, see the "Data Type Affects the Print Spooler's Modification of Client Print Jobs" section below.

Macintosh Clients

The Macintosh Print Server service assigns the RAW datatype to all jobs sent to PostScript printers, and assigns the PSCRIPT1 datatype to all jobs sent to non-PostScript print devices. There is no way to override this. For more information about specific data types, see the PSCRIPT1 topic in the "Data Type Affects the Print Spooler's Modification of Client Print Jobs" section below.

MS-DOS Applications Running Locally

If you print from an MS-DOS application that is running locally, or from a Windows NT command line utility that sends data to a printer port, NTVDM receives the print job. NTVDM queries the redirector to determine if the redirector is managing the target port (you run NET USE LPT1: \\SERVER\SHARE) or if the spooler is managing the port.

If the redirector is managing the target port, the redirector takes control of the print job, and none of the spooler options are used. If the redirector is not managing the port, but a printer defined in Print Manager is printing to that port, the print job goes to the printer, and the printer's default datatype and spooling options are used. If neither the redirector nor any printers are managing the port, then the job goes to the port device driver, unaltered.

For example, one printer in Print Manager prints to COM1, none of the printers in Print Manager print to LPT1, and 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 print job goes to the network print share. If the application prints to COM1, NTVDM submits the print job to the printer that prints to COM1, and used that printer's default datatype. If the application prints to LPT1, NTVDM submits the job directly to the parallel port device driver; no alteration occurs.

Third Party Services

Third-party software vendors may create other Windows NT services that can submit jobs to the spooler. These services may implement any logic they choose in deciding what datatype to assign each job, or whether to assign a datatype at all.

Data Type Affects the Print Spooler's Modification of Client Print Jobs

Windows NT defines six datatypes (RAW, RAW [FF Appended] RAW, RAW [FF Auto], TEXT, PSCRIPT1, and NT JNL 1.000) to implement six different print job alterations. Third-party software vendors can create their own datatypes to implement custom alterations.

RAW

The RAW datatype indicates the spooler should not alter the job. If a client assigns this datatype, the spooler passes the print job through without altering it. When you create a printer in Print Manager, the default datatype is initially set to RAW. So, most jobs from Microsoft network-based clients are assigned the RAW datatype.

RAW [FF Appended]

The RAW [FF Appended] datatype indicates the spooler should assume the job is from an application that does not append a form-feed character (0x0C) to the end of each print job. Without a trailing form-feed, the last page of the job will not print when sent to a PCL print device. To prevent this problem, the spooler appends a form-feed character to the end of the print job, but makes no other alterations. Although none of the Windows NT applications assign this datatype, you can make this datatype the system default so that it affects jobs from Microsoft network-based clients.

RAW [FF Auto]

The RAW [FF Auto] datatype indicates the spooler should check for a form- feed character at the end of the job and add one if one is not already present. The spooler makes no other changes. Although none of the Windows NT applications assign this datatype, you can make this datatype the system default so that it affects jobs from Microsoft network-based clients.

TEXT

The TEXT datatype indicates that the job consists of ANSI text. The spooler uses the current printer driver to create a new print job that prints the text of the original job using the print device's factory default font, and uses the form, orientation, resolution, set in Print Manager.

This is useful when the client application print job consists of simple text, but the target print device cannot interpret simple text jobs (for example, PostScript print devices). Most datatype problems result from print jobs that are assigned the TEXT datatype when you expect them to be assigned the RAW datatype. There are two common symptoms:

• When you send a simple text job, it prints correctly. When you send a printer-language job, the printer language code prints on the page. For example, when you send a PostScript job, you see PostScript code on the page, and when you send a PCL job, you see PCL code on the page.
• When the print job consists of text with extended characters (characters with values are between 128 and 255), but the application that created the print job does not use the ANSI character set, the extended characters print incorrectly.

  Text files actually consist of numeric values from 0 to 255, where each value is mapped to a particular character or symbol. There are several character mapping schemes (character sets) in common use, and text files contain no indication of which character set to use when displaying or printing the file. The TEXT datatype assumes the ANSI character set, so it may print some characters incorrectly if the application that created the print 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.

  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.

        Character                PC-850   ANSI     PC-437   Roman-8
        -----------------------------------------------------------
        Lowercase C Cedilla      135      231      135      181
        Lowercase AE Diphthong   145      230      145      215
        Lowercase N Tilde        164      241      164      183
        Lowercase Eth            208      240       -       228
        Lowercase Es-zet         225      223      225      222
  
  

PSCRIPT1

The PSCRIPT1 datatype is only available on Windows NT Advanced Server and Windows NT Server when Services for Macintosh (SFM) is installed. This datatype indicates that the job is Level 1 PostScript code from a Macintosh client, but the target printer is not a PostScript printer. The spooler sends the PostScript code through a TrueImage raster image processor (RIP), supplied with Services for Macintosh. The TrueImage RIP creates a series of one-page, monochrome bitmaps at up to 300 DPI. The spooler sends the RIP bitmaps to the target printer driver, and the driver returns a print job that prints the bitmaps.

Because the RIP bitmaps are monochrome and not more than 300 DPI, the target printer driver produces final output that is monochrome and not more than 300 DPI, even if the target printer driver supports color or supports higher resolutions. Similarly, the Windows NT PostScript driver is a Level 2 driver, but the RIP does not rely on the PostScript driver to generate its bitmaps. In short, the RIP's restrictions (and therefore the PSCRIPT1 restrictions) are in the RIP software itself, not in the Windows NT printer drivers.

These restrictions should not affect most business users. However, several third-party, Win32 RIP packages are commercially available for Windows NT, for customers who need a more full-featured RIP.

NT JNL 1.000

The NT JNL 1.000 datatype (usually called "Journal") indicates that the job is being sent from a Windows-based application (either 16-bit or 32- bit) running on the Windows NT print server. It also indicates that the target printer was established in Print Manager using the Create Printer option. In this case, the application uses GDI commands to describe the output. The Windows NT GDI32 component and the printer driver partially rendered the print job using device driver interface (DDI) commands and then return control to the application. As a result, the application finishes its print operation faster than normal. GDI32 then submits the DDI commands (a "journal file") to the spooler (in the background), with the datatype set to "NT JNL 1.000." The spooler calls GDI32 to finish rendering the job into printer language commands.

Third-Party Print Processor Software

Third-party software vendors can create their own print processor software to supply new data types.