jfw@uunet.uu.net (John Williams) (01/13/89)
We have just installed a PC-NFS (version 3.0) Sun3-4 (version 4.0.1)
workgroup. A Sun 3/50 is acting as our print server for a Sun LaserWriter
II. The TranScript suite has been installed and works great for our Sun
systems but the PCs can't seem to utilize the PostScript features
available with this printer.
Our PC users would like to print MS Draw and Write files to this network
printer but even though these packages support PostSript devices, we
cannot seem to make this configuration work. They can however print their
text files without any problems.
I have tried to move over MS Word PostScript files without success.
Any thoughts would be appreciated.
UUCP: ...!{uunet,bridge2}!auspex!jfw (408) 970-8970
USPS: John Williams/ Auspex Systems/ 2903 Bunker Hill Ln/ Santa Clara CA 95054stefano@trzdor1.ico.olivetti.com (Stefano Piccardi) (01/19/89)
John Williams <...!{uunet,bridge2}!auspex!jfw> writes: >Our PC users would like to print MS Draw and Write files to this network >printer but even though these packages support PostSript devices, we >cannot seem to make this configuration work. They can however print their >text files without any problems. I had the same problem. The MS-WINDOWS PostScript device driver sends a control-D character between print jobs, and PC-NFS seems unable to cope with that. This results in incomplete PostScript files being queued to the lpr spooler, and almost surely in aborts from your PostScript printer. Before I tell you my solution, though, let me explain its pros and cons: Pros: 1) It does allow you to utilize your Transcript-driven PostScript printer from your PCs. Cons: 1) The printing process is not fully automated. 2) Sometimes it does not work, although I strongly suspect the PC-NFS spooling software is faulty. In order to fix the problem you will have to: 1) Patch the MS-DOS PostScript device driver. 2) Modify, re-compile and re-install a Transcript module. 3) Reconfigure your MS-WINDOWS printer device. 4) Train users to use the correct printing procedure. 1) Using PCTOOLS with file PSCRIPT.DRV in your WINDOWS directory search for "%%". Right before it you will find the string "%c". Change it into "%d". Consequently, spooled files will start with "4%" instead of "^D%". Save your changes and re-install this modified driver into all PCs. 2) Edit pscomm.c in your Transcript distribution. Right before the comment /* here is where you might test for other file type * e.g., PRESS, imPRESS, DVI, Mac-generated, etc. */ add else if (strncmp(magic,"4%",2) == 0) { /* from PC-NFS spooler */ canReverse = FALSE; goto go_ahead; } Then re-compile and re-install pscomm. 3) On all PCs, using the MS-WINDOWS control panel select the PostScript printer to print to a disk file, for instance SPOOL.PRN. You might have to modify WIN.INI in order to do that. 4) The correct printing procedure is 1) print a file (output is spooled to SPOOL.PRN), 2) enter DOS and execute the PC-NFS print command "NET PRINT". Text files were correctly printed because PSCRIPT.DRV is not used to print them. Stefano Piccardi, Direzione Olivetti Ricerca
jdh@bu-it.bu.edu (Jason Heirtzler) (01/25/89)
I installed about 30 PCs with a mix of PC-NFS 2.0 and 3.0 about a year ago
or so. These PCs use TI2115 printers hooked up off a Sun-3/280 with SunOS
3.4
My experience was that printing from MS Word is incompatible with PC-NFS.
The problem was caused because MS Word wants to download some PostScript
macro-like definitions and wants to use them when you send your job. The
definition file is supplied in your MS Word diskettes. I can't remember
the name of the file at the moment, though.
This is all from memory, but I think we kludged the printing by
redirecting MS Word output to a file, and prepending the definitions, then
sending it to the printer (via net print)
In the PostScript definition file you have to remove the line that says
something like "if known msdict stop" and remove a ^D which lurks near the
end.
---Jason Heirtzler
jdh@bu-it.bu.edu
PS. I think they document the incompatibility in the "READ ME FIRST"
in 3.0; too bad it wasn't documented in 2.0, when we bought it.