Path: utzoo!attcan!uunet!husc6!bloom-beacon!apple!bionet!agate!ucbvax!GSB-WHY.STANFORD.EDU!A.Eric
From: A.Eric@GSB-WHY.STANFORD.EDU (Eric M. Berg)
Newsgroups: comp.protocols.appletalk
Subject: Re:  Appletalk for PC's?
Message-ID: <12448197447.12.A.ERIC@GSB-WHY.Stanford.EDU>
Date: 21 Nov 88 02:30:52 GMT
References: <Added.0XUQ1Ay00UkTQCck9n@andrew.cmu.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: A.ERIC@gsb-how.stanford.edu
Organization: Price Waterhouse Technology Centre, Menlo Park, CA
Lines: 57

>>  We run PCNFS, Sun's PC version of NFS, on the PCs, and NFS on the UNIX
>>  machine, a VAX in our case. We also run the CAP code on the VAX and
>>  use papif as spooler.
    
>>  The PC users just issue a "NET USE lpt1: \\hostname\printername" command
>>  (usually in the autoexec.bat) where "printername" is the UNIX name of the
>>  LW printer (the name in /etc/printcap), and bingo! all the output to lpt1:
>>  ends up going to the LW.

We have a similar setup (except that we're using TOPS rather than CAP on
our Unix system); however, in our experience, it isn't quite as easy as this.

A major problem is that many DOS applications don't generate fully
conforming PostScript; in particular, the PostScript they generate doesn't
begin with the two character "magic number" of "%!".  (Microsoft
applications, such as MS Word or "Write" under MS Windows, are examples of
applications with this "feature".)

Now, the Unix-based LaserWriter spooling software (i.e. Transcript from
Adobe, or TOPSprint from TOPS) looks for that "magic number" in order to
decide whether the print job is already PostScript (and should thus be
sent to the printer as is), or is plain text (and should thus be prefixed
with a header of PostScript code which essentially says "take the rest of
this file after the header and list it on the printer").  

As a result, the DOS user prints a MS Word document, the output goes via
PS-NFS to the Unix server, the print spooler looks for and can't find the
magic number, so it decides the file is really plain ASCII text, and you
get pages and pages of PostScript code being listed on your printer,
rather than the document you wanted printed.

Another problem is that applications often don't generate real PostScript;
instead, they generate something which contains application-specific
commands, and then send the printer a set of dictionary routines which
define these commands in terms of PostScript primitives.  So you have to
make sure that this initialization file is sent to the printer before your
document is printed.  Again, this isn't always as smooth as one would like;
the DOS applications seem to be have been constructed on the model of a
printer connected directly to a single PC, rather than on the basis of a
network printing environment where the printer's state can vary because of
jobs printed by other users.

We've been able to get around the problems by (1) having our users print
to a file instead of directly to the printer; and (2) then having them run
a DOS command file which takes sends first the initialization file, then
the document, to the printer, making sure that the first line of each is
the characters "%!".  Needless to say, this is kind of a nuisance.

If anyone is aware of an easier way to make this all work, I'd be delighted
to hear of it!  I tried modifying Microsoft Word's printer driver for
PostScript to put the "%!" at the beginning of each output file, but there
wasn't enough flexibility in the driver to be able to do it.


					Eric Berg
					Price Waterhouse Technology Centre
-------