The FreeBSD Corporate Networker's Guide, Chapter 8

Ted Mittelstaedt

This is a complete chapter from the recently-published book, The FreeBSD Corporate Networker's Guide.

Chapter 8

Printserving

Printserving is a complicated topic. There are many different software interfaces to printers, as well as a wide variety of printer hardware interfaces. This chapter covers the basics of setting up a print queue, using Samba to print, and administering print queues and connections.

PC Printing History

In the early days of the personal computer, printing was simple. The PC owner bought a cheap printer, usually a dot matrix that barely supported ASCII, and plugged it into the computer with a parallel cable. Applications would either work with the printer or not, and most of them did because all they could do was output DOS or ASCII text. The few software applications that supported graphics generally could output only on specific makes and models of printers. Shared network printing, if it existed, was usually done by some type of serial port switchbox.

This was the general state of affairs with the PC until the Windows operating system was released. All at once, application programmers were finally free of the restrictions of worrying about how some printer manufacturer would change printer control codes. Graphics printing, in the form of fonts and images, was added to most applications, and demand for it rapidly increased across the corporation. Large, high-capacity laser printers designed for office printing appeared on the scene. Printing went from 150 to 300 to 600dpi for the common desktop laser printer.

Today organizational network printing is complex, and printers themselves are more complicated. Most organizations find that sharing a few high-quality laser printers is much more cost effective than buying many cheaper dot-matrix units. Good network printserving is a necessity, and it can be very well provided by the FreeBSD UNIX system.

Printer Communication Protocols and Hardware

Printers that don't use proprietary vendor codes communicate with computers using one or more of three major printing protocols. The communication is done over a hardware cable that can be a parallel connection (printer port) or a serial connection (COM port).

ASCII Printing Protocol

The ASCII protocol is the simplest protocol used, as well as the oldest. ASCII is also used to represent text files internally in the DOS, UNIX, and Windows operating systems. Therefore, data taken from a text file or a directory listing generally requires little preparation before being sent to the printer other than a newline-to-carriage return/linefeed conversion for UNIX. Printers usually follow the DOS text file convention of requiring an explicit carriage return character followed by a linefeed character at the end of a line of text. Since UNIX uses only the linefeed character to terminate text, an additional carriage return character must be added to the end of each line in raw text print output; otherwise, text prints in a stairstep output. (Some printers have hardware or software switches to do the conversion.)

PostScript Printing Protocol

Adobe introduced the PostScript language in 1985; it is used to enable the printout of high-quality graphics and styled font text. PostScript is now the de facto print standard in the UNIX community and the only print standard in the Macintosh community. Numerous UNIX utilities exist to beautify and enhance text printing with PostScript. PostScript can be used to download font files into a printer as well as the data to be printed. PostScript commands can be sent to instruct the printer CPU to image, rotate, and scale complex graphics and images, thus freeing the host CPU. Scaling is particularly important with fonts since the document with the font has been produced on a computer screen with far lower resolution than the printer. For example, a 1,024 X 768 computer screen on a 17-inch monitor allows for a resolution of approximately 82dpi, but a modern desktop printer prints at a resolution of 600dpi. Therefore, a font must be scaled at least seven times larger for WYSIWYG output.

PostScript printers generally come with a number of resident fonts. For example, the NEC Silentwriter 95 contains Courier, Helvetica, ITC Avant Garde, Gothic Book, ITC Bookman Light, New Century Schoolbook Roman, Palatino Roman, Times Roman, and several symbol fonts. These are stored in ROM in the printer. When a page prints from a Windows client that contains a font not in the printer, a font substitution table is used. If no substitute can be made, Courier is usually used. The user should be conscious of this when creating documents—documents with fonts not listed in the substitution table may cause other users problems when printing. Avoid use of strange fonts for documents that will be widely distributed.

The user program can choose to download different fonts as outline fonts to the PostScript printer if desired. Fonts that are commonly used by a user are often downloaded to PostScript printers that are connected directly to the user's computer; the fonts are then available for successive print jobs until the printer is turned off. When PostScript printers are networked, clients must download any fonts desired with each print job. Since jobs come from different clients, clients cannot assume that downloaded fonts are still in the printer.

PostScript print jobs also contain a header that is sent describing the page layout, among other things. On a shared network printer, this header must also be downloaded with each print job. Although some PostScript drivers allow downloading of the header only once, this usually requires a bidirectional serial connection to the printer instead of a unidirectional parallel connection.

PostScript print jobs can be sent either as binary data or as ASCII. The main advantage of binary data transmission is that it is faster. However, not all PostScript printers support it, and fonts generally cannot be downloaded in binary. When FreeBSD is used as a printserver, ASCII PostScript printing should be selected on the clients; this is the default with most PostScript drivers.

The Adobe company licenses PostScript interpreters as well as resident fonts to printer manufacturers, and extracts a hefty license fee from any printer manufacturer who wants to use them in its printer. This presents both a benefit and a problem to the end user. Although a single company holding control over a standard can guarantee compliance, it does significantly raise the cost of the printer. As a result, PostScript has not met with much success in lower-end laser and inkjet Windows printing market, despite the fact that Adobe distributes PostScript software operating system drivers for free.

One issue that is a concern when networking PostScript printers is the selection of banner page (also known as header page or burst page) printing. UNIX shared printing began with ASCII line printers, and since UNIX is a multiuser system, often many different user print jobs would pile up in the printer output hopper. To separate these jobs the UNIX printing system programs support banner page printing if the client program that submits jobs asks for them. These pages print at the beginning or end of every print job and contain the username, submittal date, and so on. By default, most clients, whether remote (e.g., a Windows LPR client) or local (e.g., the /usr/bin/lpr program) trigger a banner page to be printed. One problem is that some PostScript printers abort the entire job if they get unformatted ASCII text instead of PostScript. (In general, PostScript printers compatible with Hewlett-Packard Printer Control Language [HPPCL] handle banners without problems.) Banner printing should be disabled for any printers with this problem unless PostScript banner page printing is set up on the server.

HPPCL Printing Protocol

The Hewlett-Packard (HP) company currently holds the largest market share of desktop inkjet and office laser printers. Back when Windows was released, HP decided to expand into the desktop laser jet market with the first LaserJet series of printers. At the time there was much pressure on Microsoft to use Adobe Type Manager for scalable fonts within Windows and to print PostScript to higher-end printers. Microsoft decided against doing this and used a technically inferior font standard, Truetype. They thought it was unlikely that the user would download fonts to the printer since desktop publishing was not being done on PCs at the time. Instead, users would rasterize the entire page to the printer using whatever proprietary graphics printer codes the selected printer needed. HP devised HPPCL for their LaserJets and made PostScript an add-on. The current revision of HPPCL allows for many of the same scaling and font download commands that PostScript does. HP laser jet printers that support PostScript can be distinguished by the letter "M" in the model number. (M is for Macintosh, because Macintosh requires PostScript to print.) For example, the HP 6MP has PostScript; the 6P doesn't.

HPPCL has almost no support in the UNIX applications market, and it is very unlikely that any will appear soon. One big reason is the development of the free Ghostscript PostScript interpreter. Ghostscript can take a PostScript input stream and print it on a PCL printer under UNIX. Another reason is the UNIX community's dislike of reinventing the wheel. HPPCL has no advantage over PostScript, and in many ways there are fewer problems with PostScript. Considering that PostScript can be added to a printer, either by hardware or use of Ghostscript, what is the point of exchanging an existing working solution for a slightly technically inferior one? Over the life of the printer, taking into account the costs of toner, paper, and maintenance, the initial higher cost of PostScript support is infinitesimal.

Network Printing Basics

The most common network printing implementation is a printserver accepting print jobs from clients tied to the server via a network cable.

Printservers

The term printserver is one of those networking terms, like packet, that has been carelessly tossed around until its meaning has become somewhat confusing and blurred. To be specific, a printserver is simply a program that arbitrates print data from multiple clients for a single printer. Printservers can be implemented by one of four methods described in the following sections.

Printserver on a Fileserver

A printer can be physically cabled to the PC running the NOS (Figure 8.1). Print jobs are submitted by clients to the printserver software on the fileserver, which sends them down the parallel or serial cable to the printer. The printer must be physically close to the fileserver. This kind of printserving is popular in smaller workgroup networks in smaller offices.

Printserver on a Separate PC

It is possible to run a printserver program on a cheap PC that is located next to the printer and plugged into it via parallel cable (Figure 8.2). This program simply acts as a pass-through program, taking network packets from the network interface and passing them to the printer. This kind of server doesn't allow any manipulation of print jobs; jobs usually come from a central file server, where jobs are controlled.

Figure 8.1 Printserver on a fileserver

Figure 8.2 Printserver on a separate PC

Printserver on a Separate Hardware Box

A printserver on a separate hardware box is exemplified by network devices such as the Intel Netport, the HP JetDirect Ex, the Osicom/DPI NETPrint, and the Lexmark MarkNet (Figure 8.3). Basically, these are plastic boxes with an Ethernet connection on one side and a parallel port on the other. Like a printserver on a PC, these devices don't allow remote job manipulation and merely pass packets from the network down the parallel port to the printer.

Printserver in the Printer

The HP JetDirect Internal is the best known printserver of this type (Figure 8.4). It is inserted into a slot in the printer case, and it works identically to the external JetDirect units.

Figure 8.3 Printserver on a hardware box

Figure 8.4 Printserver in the printer

Print Spools

Print spooling is an integral part of network printing. Since the PC can spit out data much faster than the printer can accept it, the data must be buffered in a spool at some location. In addition, because many clients share printers, when clients send print jobs at the same time, jobs must be placed in a queue so that one can be printed after the other.

Logical Location of the Print Spool

Print spooling can be implemented at one of three locations (see Figure 8.5).

1. The client. Clients can be required to spool their own print jobs on their own disks. For example, when a Windows client application generates a print job, the job must be placed on the local client's hard drive. Once the remote printserver is free to accept the job, it signals the client to start sending the job a bit at a time. Client spooling is popular in peer-to-peer networks with no defined central fileserver. However, it is impossible for a central administrator to perform advanced print job management tasks, such as moving a particular print job ahead of another or deleting jobs.

2. The printserver. If each printer on the network is allocated its own combination print spoolerÐprintserver, jobs can stack at the printer. Many of the larger printers with internal printservers have internal hard drives for this purpose. Although this enables basic job management, it still restricts the ability to move jobs from one printer to another.

3. A central print spooler on a fileserver. Print jobs are received from all clients on the network in the spool and then dispatched to the appropriate printer. This scheme is the best for locations with several busy printers and many clients. Administration is extremely simple because all print jobs are spooled on a central server, which is particularly important in bigger organizations. Many large organizations have standardized on PostScript printing for all printing; in the event that a particular printer fails and is offline, incoming PostScript print jobs can be rerouted automatically to another printer. Since all printers and clients are using PostScript, clients don't need to be reconfigured when this happens. Print jobs appear the same whether printed on a four-page-per-minute NEC Silentwriter 95 or a 24-page-per-minute HP LaserJet 5SiMX if both printers are defined in the client as PostScript printers.

Figure 8.5 Print spool locations

FreeBSD is an excellent platform to implement centralized printserving and print spooling. The rest of this chapter concentrates on the centralized print spooler model. Note that PostScript printing is not a requirement for this model —the HPPCL protocol can be the standard print protocol as well. For transparent printing between printers with HPPCL, however, the printer models must be similar.

Physical Location of the Print Spool

In some companies, the central fileserver is often placed in a closet, locked away. Printers, on the other hand, are best located in high-traffic areas for ease of use. Network printing works best when the printers are evenly distributed throughout the organization. Attempting to place all the major printers in one location, as technically advantageous as it may seem, merely provokes users to request smaller printers that are more convenient for a quick print job. The administrator may end up with a data center full of nice, expensive printers that are never used while the smaller personal laser printers scattered throughout the plant bear most of the printing load.

The big problem with this situation is that scattering printers throughout the organization makes it difficult to use the three possible parallel ports on the fileserver due to parallel port distance limitations. Although high-speed serial ports may extend that distance, not many printers have good serial ports on them. This is where the hardware network printserver devices can come into play. I prefer using these devices because they are much cheaper and more reliable than a standalone PC running printserver software. For example, Castelle (http://www.castelle.com) sells the LANpress 1P/10BT printserver for about $170. Using these devices, a FreeBSD UNIX server can have dozens of print spools accepting print jobs and then route them back out over the network to these remote printserver boxes. If these kinds of hardware servers are used, they must support the Line Printer Daemon (LPD) print protocol.

With a scheme like this, it is important to have enough disk space on the spool to handle the print jobs. A single large PowerPoint presentation PostScript print job containing many graphics may be over 100MB. When many such jobs stack up in the print spool waiting to print, the print spooler should have several gigabytes of free disk space available.

Network Printing to Remote Spools

Although several proprietary network printing protocols, such as Banyan Vines and NetWare, are tied to proprietary protocols, FreeBSD UNIX can use two TCP/IP network printing protocols to print to remote print spools. The two print protocols available on TCP/IP with FreeBSD are the open LPD protocol and the NetBIOS-over-TCP/IP Server Messaging Block (SMB) print protocol first defined by Intel and Microsoft and later used by IBM and Microsoft. The LPD protocol is defined in RFC1179. This network protocol is the standard print protocol used on all UNIX systems. LPD client implementations exist for all Windows operating systems and DOS. Microsoft has written LPD for the Windows NT versions; the other Windows operating system implementations are provided by third parties.

The Microsoft Networking network protocol that runs on top of SMB can use NetBIOS over TCP/IP, as defined in RFC1001 and RFC1002. This protocol has a specification for printing that is the same print protocol used to send print jobs to NT server by Microsoft clients. To implement this protocol on FreeBSD requires the installation of the Samba client suite of programs discussed in Chapter 7.

Setting Up Line Printer Remote on Windows Clients

The program clients use to print via LPD is the Line Printer Remote, or LPR, program. The following instructions cover enabling this program on Windows clients.

Windows 3.1 and Windows for Workgroups 3.11

Several commercial TCP/IP stacks are available for Win31 that provide LPR client programs, in addition to the basic TCP/IP protocol, to Win31. WfW has TCP/IP networking available for free from Microsoft, but it doesn't include an LPR client. Unfortunately, I have not come across a freeware implementation of a 16-bit Windows LPR client, so with the following instructions I use the shareware program WLPRSPL, available from http://www.winsite.com/ info/pc/win3/winsock/wlprs41.zip. This program must be active during client printing and is usually placed in the Startup group.

Organizations that want to use UNIX as a printserver to a group of Win31 clients without using a commercial or shareware LPR program have another option. The Microsoft Networking client for DOS used underneath Win31 contains SMB-based printing, which is covered later in this chapter. DOS networking client setup and use are covered in Chapter 2 and Chapter 7.

If LPR-based client printing is desired and the organization doesn't want to upgrade to Win95 (which has several LPR clients), the following instructions can be used. WLPRSPL needs a Winsock under Windows 3.1, so for the example, I explain the setup of the Novell 16-bit TCP/IP client. The stack can be FTPed from Novell and is easy to integrate into sites that already use the 16-bit NetWare networking client, usually NW 3.11 and 3.12. In most cases, however, sites that use NetWare plus Win31 are probably best off printing through the NetWare server and then loading an LPR spooler as a Netware Loadable Module (NLM) to send the job over to FreeBSD.

As an alternate, the Microsoft Networking DOS 16-bit TCP/IP client under Win31 contains a Winsock, as does Microsoft TCP/IP for WfW. The target machine used here is a Compaq Deskpro 386/33 with 12MB of RAM with an operating version of Windows 3.1, and a 3Com 3C579 EISA network card. The instructions assume an LPR printserver on the network, named mainprinter.ayedomain.com, with a print queue named raw (see Exhibits 8.1 and 8.2).

Use the installation instructions in Exhibit 8.1 for a quick and dirty TCP/IP Winsock for Win31 systems. Administrators who already have the Novell IPX client installed should skip those steps.

Exhibit 8.1ÊInstalling the Novell TCP/IP Winsock client

1. Make sure that the machine has enough environment space (2,048 bytes or more) by adding the following line to the config.sys file and rebooting.

SHELL=C:\COMMAND.COM /E:2048 /P

2. Obtain the TCP16.EXE file from ftp3.novell.com/pub/updates/eol/nweol/tcp16.exe.

3. Obtain the Network Adapter support diskette for the network card in your machine. This should be supplied with the card or available via FTP from the network adapter manufacturer's FTP site.

4. Now you need the file LSL.COM, which is available on some Network Adapter Driver diskettes. It used to be available from the VLM121_2.EXE file from Novell, but unfortunately, this file is no longer publicly accessible from Novell.

5. If you have vlm121_2.exe in a temporary directory, run it. This will extract a number of files.

6. One of the files extracted is LSL.CO_. Extract this file with the command nwunpack lsl.co_.

7. Create the directory c:\nwclient. Then, copy lsl.com from the temporary directory into the directory.

8. Obtain and install the printer driver for the model of printer that you will be spooling to, and point it to LPT1:. Win31 and WfW 3.11 have an incomplete printer driver list, so if you need a driver, Microsoft has many Win16 printer drivers on their FTP site. A list is available at ftp://ftp.microsoft.com/Softlib/index.txt. In addition, if you are installing a PostScript printer driver for a printer supplied in Win31, it may be necessary to patch the driver. The Microsoft PostScript driver supplied in Win31 is version 3.5. (The patch named PSCRIP.EXE, which brought the PostScript driver to version 3.58, is no longer publicly available.) WfW already uses the more recent PostScript driver, as does Win31 version A. Installing the Adobe PostScript driver for Win31 is also an option (see http://www.adobe.com/support/downloads/pdrvwin.htm for the version 3.1.2 Win31 PostScript driver).

9. Look on the network adapter driver disk for the subdirectory nwclient, and then look for the ODI driver with the adapter card. For example, on the 3Com 3C509/3C579 adapter driver disk, the driver and location are \NWCLIENT\3C5X9.COM. Copy this driver to the c:\nwclient directory.

10. Create a file called NET.CFG in the c:\nwclient directory. Often, the network card adapter driver diskette has a template for this file in the same location as the ODI driver. This template can be modified, as can the following example.

LINK SUPPORT

BUFFERS 4 1600

MEMPOOL 8192

LINK DRIVER 3C5X9

; PORT 300 (these are optional if needed by card uncomment)

; INT 10 (optional; uncomment, and modify if needed)

11. Attempt to load the network card driver. First, load lsl, and then load the ODI driver. With the 3Com card the commands are lsl 3c5x9 If the driver properly loads, it will list the hardware port and interrupt settings for the network adapter. If it has loaded properly, unload the drivers in reverse order with the /u command. 3c5x9 /u lsl /u

12. Go to the temporary directory that contains the tcp16.exe file and extract it by running the program.

13. Run the install batch file by typing installr. It should list "New Installation detected." It will then copy a number of files into nwclient, add some commented-out sections to net.cfg, and call "edit" on net.cfg.

14. Read the editing instructions and make the appropriate entries. The sample net.cfg file from above would look like this. LINK SUPPORT BUFFERS 4 1600 MEMPOOL 8192 LINK DRIVER 3C5X9 FRAME ETHERNET_II Protocol TCPIP PATH TCP_CFG c:\nwclient ip_address 192.168.1.54 LAN_NET ip_netmask 255.255.255.0 LAN_NET ip_router 192.168.1.1 LAN_NET Bind 3C5X9 #1 Ethernet_II LAN_NET Save and exit. The Installer should list "TCP16 installation completed."

15. Reload the client with the following commands. lsl 3c5x9 tcpip The TCP/IP driver should list the IP numbers and other information.

16. Optionally, either create a HOSTS file, or a RESOLV.CFG file (pointing to a nameserver), in c:\nwclient. Check to see that this is operating properly by pinging a hostname.

17. Add the c:\nwclient directory to the path, as well as the three startup commands in step 15 in autoexec.bat.

Exhibit 8.2:Installation of the LPR client on 16-bit Windows with a Winsock installed

The following assumes a running Win31 installation with a Winsock or a running WfW installation with the 32-bit Microsoft TCP/IP protocol installed.

1. Install the printer driver desired. See step 8 of Exhibit 8.1.

2. Obtain and extract into a temporary directory the wlprs41.zip file from the location mentioned above.

3. Run setup.exe from the temporary directory containing the wlprs files.

4. In setup, accept the default directory, and check Yes to add to its own group. Click "Continue" when asked for group name, and check whatever choice you want when asked to copy the doc files.

5. Click No when asked to add the program to Startup.

6. On the UNIX FreeBSD print spooler, make sure that there is an entry in /etc/hosts.lpd or /etc/hosts.equiv for the client workstation, thereby allowing it to submit jobs.

7. Double-click the Windows LPR Spooler icon in the Windows LPR Spooler group that is opened. When it asks for a valid spool directory, select the c:\wlprspl directory that the program installed its files into.

8. When asked for a valid Queue Definition File, click OK to use the default filename. The program automatically creates a queue definition file.

9. The program opens up with its menu. Click Setup in the top menu, and then select "Define New Queue."

10. For a local spool filename, just use the name of the remote queue (RAW) to which the client will print.

11. For the remote printer name, use the same name as the remote queue (RAW) to which the client prints.

12. For the remote hostname, use the machine name of the FreeBSD print spooler, mainprinter.ayedomain.com.

13. For the Description, enter a description such as "3rd floor Marketing printer."

14. For the protocol, leave the default of BSD LPR/LPD selected.

15. Click on Queue Properties, and make sure that "Print unfiltered" is selected. If you're printing PostScript, then also click the Advanced options button. Make sure that "Remove trailing Ctrl-D" is unchecked and that "Remove Leading Ctrl-D" is checked. Also with PostScript, if the printer cannot print ASCII, uncheck the "Send header page" box. (PostScript header and banner pages are discussed later in this chapter.) Exhibit 8.2Ê(continued)

16. Click OK. At the main menu of the program, click File and then "Control Panel/Printers" to bring up the Printers control panel of Windows.

17. Make sure that the "Use Print Manager" button is checked, and then highlight the printer driver and click the Connect button.

18. Scroll down to the C:\WLPRSPL\RAW entry for the spool that was built and highlight this. Click OK.

19. Minimize the Windows LPR Spooler. Copy the Windows LPR Spooler icon to the Startup group. Click "File/Properties" with the Windows LPR Spooler icon highlighted in the Startup group. Check the "Run Minimized" button.

20. Exit Windows, and when the "Save queue changes?" button comes up, click Yes.

21. Restart Windows, and make sure that the spooler starts up.

22. Open the Control Panel and look for a new yellow icon named "Set Username?' If you are running the Novell or other Winsock under Win31, click on this icon and put the username of the person using this computer into the space provided. If you are running WfW, this isn't necessary because Windows will supply the username.

22. If the spooler is not started properly in some installations, there may be a bug. If placing the icon in the Startup group doesn't actually start the spooler, the program name can be placed in the run= line of win.ini.

23. Try printing a print job from an application such as Notepad. If everything goes properly, clicking on the "Queues/Show remote printer status" in the Windows LPR menu should show the print job spooled and printing on the remote printserver. Installation of LPR Client on Windows 95/98 The wlprspl program also can be used under Windows 95, but as a 16-bit program, it is far from an optimal implementation on a 32-bit operating system. In addition, Win95 and its derivatives have fundamentally changed from Windows 3.1 in the printing subsystem. For these reasons I use a different LPR client program for Win95/98 LPR printing instructions. It is a full 32-bit print program, and it installs as a Windows 32-bit printer port monitor. The program is called ACITS LPR Remote Printing for Windows 95, and it is located at http://shadowland.cc.utexas.edu/acitslpr.htm. ACITS stands for Academic Computing and Instructional Technologies Services. The ACITS LPR client includes software developed by the University of Texas at Austin and its contributors; it was written by Glenn K. Smith, a systems analyst with the Networking Services group at the university. The filename of the archive in the original program was ACITSLPR95.EXE, and, as of version 1.4, it was free for individuals or organizations to use for their internal printing needs. Since that time, it has gotten so popular that the university has taken over the program, incremented the version number (to get out from under the free license), and charges a $35 per copy fee for commercial use for the newer versions. The older, free version can still be found on overseas FTP servers, such as http://www.go.dlr.de/fresh/pc/src/winsock/acitslpr95.exe. It is likely that the cost of a shareware or commercial LPR program for Win95 plus the cost of Win95 itself will meet or exceed that of Win2K. As such, users wishing to print via LPR to FreeBSD UNIX systems will probably find it cheaper to simply upgrade to Windows NT Workstation or Win2K. ACITS LPR and Win95 have a few printing idiosyncrasies. Most Win95 programs, such as Microsoft Word, expect print output to be spooled on the local hard drive and then metered out to a printer that is plugged into the parallel port. Network printing, on the other hand, assumes that print output will go directly from the application to the remote printserver. Under Win95, local ports have a setting under Properties, Details, Spool Settings labeled "Print directly to the printer." If this is checked, the application running on the desktop, such as Microsoft Word, does not create a little Printer icon with pages coming out of it or use some other means of showing the progress of the job as it is built. This can be very disconcerting to the user of a network printer, so this option should be checked only with printers plugged directly into the parallel port. Worse, if this is checked with ACITS, it can cause the job to abort if the remote print spooler momentarily goes offline. Another local setting also should be changed. Generally with local ports, Win95 builds the first page in the spooler and then starts printing it while the rest of the pages spool. If ACITS starts printing the first page while the rest of the pages are building, timeouts at the network layer can sometimes cause very large jobs to abort. The entire job should be set to spool completely before the LPR client passes it to the UNIX spooler. This problem is partly the result of program design: because ACITS is implemented as a local printer port instead of being embedded into Win95 networking (and available in Network Neighborhood), the program acts like a local printer port in some ways. The LPR program can be set to deselect banner or burst page printing if a PostScript printer that cannot support ASCII is used. The burst pages referred to here are not generated by the Windows machine. Use the instructions in Exhibit 8.3 to install.

Exhibit 8.3:LPR client on Win95/98 installation instructions

1. Obtain the ACITSLPR95.EXE file and place it in a temporary directory, such as c:\temp1.

2. Close all running programs on the desktop. The computer must be rebooted at completion of installation or the program will not work.

3. Click Start, Run and type in c:\temp1\acitslpr95. Click Yes at the InstallShield prompt.

4. Click Next, then Yes. The program runs through some installation and then presents a Help screen that explains how to configure an LPR port.

5. After the Help screen closes, the program asks to reboot the system. Ensur