Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!spool.mu.edu!agate!ucbvax!PANGEA.STANFORD.EDU!farrell From: farrell@PANGEA.STANFORD.EDU (Phil Farrell) Newsgroups: comp.protocols.appletalk Subject: CAP printing problem with LaserWriter 7.0 driver Message-ID: <9106052350.AA01577@pangea.Stanford.EDU> Date: 5 Jun 91 23:50:51 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 32 This is really an Apple LaserWriter driver or PostScript problem, not a CAP problem, but it may be affecting other sites running CAP as well. Any hints on this, or suggestions where else to post, would be appreciated. We just upgraded all the Macs on our network to use the new version 7.0 LaserWriter so we can be compatible with System 7.0. We use CAP (still 5.0) to let our UNIX systems print to the LaserWriters as well. One of the popular UNIX applications for printing is the TeX typesetting system. We use the standard dvi2ps driver. It inserts a "prologue" of PostScript code before the actual converted document. One part of that prologue allows the use of \special commands in the TeX document to insert PostScript figures into the TeX document. This code would redefine the standard Apple PostScript procedure "psu" to avoid some problems when including figures made with MacDraw, etc. This always worked fine before when the LaserWriter was initialized with driver version 5.2. Now, whenever someone tries to include a PostScript figure in their TeX document (triggering this section of the dvi2ps PostScript code), the LaserWriter initialized with driver version 7.0 quits, claiming that "psu" is undefined. I captured the PostScript from printing from a Mac with the LaserWriter 7.0 driver and I can see that there is in fact a "psu" procedure. Yet somehow, a LaserWriter that has been initialized with this driver thinks that "psu" is undefined when our UNIX box comes along and tries to re-define it. I really don't know PostScript at all, so I am not sure what LaserWriter 7.0 is doing differently with "psu" that is creating this problem. Anyone have any ideas? E-mail or post as desired. Thanks. -Phil Farrell, Computer Systems Manager Stanford University School of Earth Sciences farrell@pangea.stanford.edu