gil@unix.sri.com (Gil Porat) (06/23/89)
I have a Sun/PostScript question. 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? Any help would be greatly appreciated. - Gil Porat
mic@cs.utexas.edu (Mic Kaczmarczik) (06/27/89)
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
brent@uunet.uu.net (Brent Chapman) (06/28/89)
# 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?
Perhaps just the opposite. They may be treating the file like a Mac
document, and prepending (or preinstalling in the printer) a Mac driver or
prologue.
Alternatively, they may expect your program to be "structured", according
to the structuring specificiations in Appendix C of the PostScript
Language Reference Manual (more commonly known as "the red book") from
Adobe. If possible, you should follow those conventions, but if you
_don't_, make sure that your file doesn't still _claim_ to follow the
conventions. "%!" as the first two characters of the file identify it as
PostScript; "%!PS-Adobe-1.0" on the first line identifies it as conformant
with version 1.0 of the structuring conventions.
The structuring conventions, if you're curious, are what allow people to
write filter programs that can do neat things like reverse the order of
printing (print pages in descending order, instead of ascending order),
select only certain pages from a file for printing (only pages 5-10 and
20, for instance), and so on. There are many other uses for the
structuring conventions, and I believe they are, on the whole, a Good
Thing, and that it is worth the little bit of extra trouble it takes to
generate PostScript that conforms to the conventions.
-Brent
--
Brent Chapman Capital Market Technology, Inc.
Computer Operations Manager 1995 University Ave., Suite 390
brent@capmkt.com Berkeley, CA 94704
{apple,lll-tis,uunet}!capmkt!brent Phone: 415/540-6400