Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!bloom-beacon!think!husc6!rice!sun-spots-request
From: ut-emx!mic@cs.utexas.edu (Mic Kaczmarczik)
Newsgroups: comp.sys.sun
Subject: Re: I thought PostScript was PostScript!?!
Keywords: Software
Message-ID: <4201@kalliope.rice.edu>
Date: 27 Jun 89 06:52:50 GMT
Sender: usenet@rice.edu
Organization: Sun-Spots
Lines: 46
Approved: Sun-Spots@rice.edu
X-Sun-Spots-Digest: Volume 8, Issue 57, message 1 of 11

In article <4049@kalliope.rice.edu> gil@unix.sri.com (Gil Porat) writes:
>X-Sun-Spots-Digest: Volume 8, Issue 47, message 8 of 15
>
>I've produced a PostScript program which prints nicely on our Apple Laser
>Writer when I type "lpr -h myfile" (where 'myfile' is PostScript source)
>from my Sun who runs Transcript.  The PROBLEM begins when I try to have a
>local laser-print shop print 'myfile' on their LaserWriter, and
>ultimately, on their Linotronic 2540 dpi printer.  They say that printing
>fails.
>
>So any clues?  Does lpr prepend a prologue to 'myfile' which I in turn do
>not give to the print shop?

TranScript doesn't normally prepend any sort of prolog to ``pure''
PostScript files (which it recognizes by looking for the two letters
``%!'' at the beginning of the file).  Based solely on the evidence that
the job printed on your LaserWriter, but not on the LaserWriter at the
print shop, I'd bet your PostScript job uses more virtual memory (VM) than
the printers at the print shop have available. 

Why would your LaserWriter have more memory than theirs?  Well, print
shops typically use Macs to print desktop publishing jobs, and the
Macintosh LaserWriter driver automatically downloads a library of
PostScript procedures into the LaserWriter.  These routines remain loaded
after the job is done, and significantly reduce the amount of VM available
to your PostScript job.  Since your LaserWriter is connected to a Unix
machine, it never has the Mac library downloaded, and thus has more VM
available.

However, this is just guessing on my part; there are plenty of other
things that could go wrong.  The way to determine exactly what failed is
to ask the people at your print shop for the error messages the PostScript
interpreter returns over the communications line.  These messages will
help you pinpoint the specific operator or function that caused the job to
fail.  If the people at the print shop don't know how to get these
messages, I'd recommend trying a more shop with more knowledgeable people.
:-)

Mic Kaczmarczik


-- 
Mic Kaczmarczik			If you drink, don't drill.
UT Austin Computation Center			-- Matt Groening
mic@emx.utexas.edu	
MIC@UTAIVC.BITNET