Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!TERMINUS.UMD.EDU!dzoey From: dzoey@TERMINUS.UMD.EDU Newsgroups: comp.protocols.tcp-ip.ibmpc Subject: Re: Spooled LPR/LPQ Support Message-ID: <9006091845.AA03904@terminus.umd.edu> Date: 9 Jun 90 18:45:00 GMT References: <9006082038.aa05130@louie.udel.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 40 > Let me explain what I mean. Many of the PC's are running either > spreadsheet software or word processing software. If I understand > LPR/LPQ correctly, they would be DOS commands issued at the DOS > prompt on the PC's. They could be used to print a file from the PC. > What we want instead is to somehow or other remain in the spreadsheet > program or the word processing program, have the programs print > as if they were printing to a printer attached to the PC, but have > the printed output go to the LPD server. I've seen this problem solved in two ways: 1) Many (all?) implementations of nfs on the PC have a remote printing service which redirects print devices to the nfs server where the server's regular print daemon can get at them. When the spreadsheet writes to the printer, the print streams get spooled over the network. 2) Here's what we do in the labs that don't have transparent network printng. We have a small TSR that spools the print output to disk. When the user exits the application he/she is notified that there is print output generated. The user is asked to pick a queue to send the trapped output or to discard it. Method one has the advantage in that the method of printing is transparent to the user. Method two has the advantage in that you do not need to keep TCP/IP loaded in the machine all the time, just a small print spooler. I personally feel that method one is more elegant, but it does take up resources. Joe Herman U. of Md disclaimer: I work on the PC/IP project at Maryland. dzoey@terminus.umd.edu