home *** CD-ROM | disk | FTP | other *** search
/ Carousel Volume 2 #1 / carousel.iso / mactosh / unix / paintps.sha / README.SPOOL < prev   
Text File  |  1986-07-08  |  6KB  |  126 lines
  1.  
  2.    Paintps depends on the "Mac environment" being present in the LaserWriter
  3. at the time its Postscript output is processed.  This environment is setup
  4. by the laser-prep prolog file which is prepended by the Mac print drivers
  5. when a Mac prints directly to a LaserWriter.  Since paintps basically
  6. mimics what MacPaint does when it prints a file on a LW, something needs
  7. to be done to provide the Mac environment in the LW with the Unix system.
  8.  
  9.    The same applies to any "Mac PostScript" file produced on a Mac and
  10. captured with the Command-F sequence and then uploaded to a Unix machine.
  11. The remaining discussion concerns printing Mac files to a LaserWriter
  12. being driven by a Unix (4.2 or 4.3 BSD) spooler and which is primarily
  13. used for general text processing, not for Mac output.  The output of
  14. paintps is considered a "Mac file", even though it's produced on a
  15. Unix system, and is included in the general discussion below.
  16.  
  17.    The first step is to get the laser-prep prolog file, so that it can be
  18. sent to the LW via the spooler.  The laser-prep file must be modified
  19. for use with the spooler.  There are two reasons why.
  20.     1) The standard laser-prep installs itself permanently, on the
  21.        assumption that the LW is living in a Mac-only universe.  The
  22.        amount of memory it consumes is substantial and we aren't
  23.        willing to give it away to accomodate the occasional Mac
  24.        job sent via the Unix spooler.  Removing the few lines
  25.        at the beginning which escape from the server loop is
  26.        sufficient to prevent permanent residency.
  27.     2) The encrypted smoothing function in the laser-prep is fed
  28.        as stdin to an eexec command which will read until eof.  Since
  29.        what we're trying to accomplish is to have the laser-prep only
  30.        live for the duration of a single job, this presents a problem.
  31.        Luckily the eexec command will also accept a string argument
  32.        on the stack, so by placing hex quotes (<>) around the smoothing
  33.        code and calling eexec after it has been placed on the stack,
  34.        we get the same effect plus the ability to continue sending
  35.        PostScript code afterwards.  Hence, we can simply concatenate
  36.        the modified laser-prep and the Mac PostScript file and send
  37.        it to the printer, the Mac environment will be there for the
  38.        job and will be flushed afterwards.
  39.    This will also allow us to support more than one version of the LaserWriter
  40. driver in the future (which we intend to do.)  Since the laser-prep won't be
  41. in the LW RAM, we can prepend any laser-prep without causing a conflict.
  42.  
  43.    Now, there are a couple of ways to handle a Mac PostScript job via
  44. the Unix spooler.
  45.     1) On the front end of the spooler thru lpr, such as:
  46.         paintps foo.mp > foo.ps
  47.         cat /usr/local/lib/laser-prep.pro foo.ps | lpr -Plw
  48.        This is the most generic and doesn't require anything special
  49.        be done on the unix system.  The drawbacks are that a current
  50.        copy of the laser-prep must be present on every system that might
  51.        spool a job, that users know where it is, and that they know
  52.        the proper incantations.  A shell script could be written to
  53.        hide the above commands, but that still requires multiple
  54.        copies of the laser-prep file.
  55.     2) In the back end of the spooler, by having a filter automatically
  56.        prepend the laser-prep to all Mac PostScript jobs.  This is 
  57.        the most elegant way to handle it, since only one copy of the
  58.        laser-prep need exist on the system where the printer is, and
  59.        the details of handling Mac specific files are hidden from
  60.        the user.  This method requires selecting a "file type" for
  61.        spooling Mac jobs and specifying the proper handlers on the
  62.        system where the printer is.  At UT we chose the "Fortran"
  63.        file type, since it was unused.  Others could be used but
  64.        there aren't many candidates, especially if you already
  65.        support ditroff and/or TeX.  We handle spooling of Mac files
  66.        with a shell script which simply calls lpr and adds the -f
  67.        file type flag.
  68.  
  69.    The discussion below assumes the reader is familiar with how the 
  70. Berkeley spooler works and knows how to setup filters.  The person
  71. who does this must have super-user access anyway.  Once again there
  72. are two ways to go about setting up your spooler to handle Mac PostScript
  73. files:
  74.     1) If you're using the standard Transcript setup, use the psmac
  75.        shell script included.  Put it in /usr/local/lib, or where
  76.        you keep the rest of your filters, and put its name in the
  77.        printcap slot for whichever file type you use (the rf field
  78.        is for the Fortran type, go figure).
  79.     2) If you're using an Imagen-style shell script which is called
  80.        by several different names, use our psfilter (included) as
  81.        a guide and include a case for handling Mac files as shown.
  82.        This approach is kind of odd, and can lead to various problems,
  83.        but allows more flexibility and enables you to do things
  84.        like complex pipelines and problem notification.  Psfilter
  85.        is what we use at UT, you may or may not find it useful.
  86.        In any case you can ignore the local hacks for dealing
  87.        with LaserWriters on Bridges (unless you have some, I might
  88.        be able to help).
  89.  
  90.    The program macfilter, named in both psmac and psfilter, does nothing
  91. more than convert any non-printable characters in the data stream to 
  92. the octal equivalent.  Apple broke the rules and used non-printable
  93. characters (specifically non-ascii > 128) for certain symbols.  These
  94. don't survice the unix device driver (they lose the high bit) and raw
  95. mode is not possible because the LW needs to use flow control.
  96.  
  97.    Here is the /etc/printcap we use here at UT:
  98. #
  99. #
  100. # Apple LaserWriter
  101. # sb MUST be specified, psof depends on it.  psof prints job header page.
  102. # rw must be specified, printer talks back to psif
  103.  
  104. lw-generic|Apple Laserwriter:\
  105.     :rw:br#9600:ff=:tr=^D:sc:sb:\
  106.     :of=/usr/local/lib/psof:\
  107.     :df=/usr/local/lib/psdvi:\
  108.     :nf=/usr/local/lib/psditroff:\
  109.     :tf=/usr/local/lib/pscat:\
  110.     :if=/usr/local/lib/psasc:\
  111.     :cf=/usr/local/lib/psbad:\
  112.     :gf=/usr/local/lib/psbad:\
  113.     :vf=/usr/local/lib/psbad:\
  114.     :rf=/usr/local/lib/psmac:
  115.  
  116. Lazarus|lw1|lw|lazarus|LW connected to im4u:\
  117.     :lp=/dev/lw:sd=/usr/spool/lw1:\
  118.     :xs#040400:fc#070:fs#00302:\
  119.     :lf=/usr/adm/log-lw1:\
  120.     :af=/usr/adm/lw.acct/lw1:\
  121.     :tc=lw-generic:
  122. -------------------
  123. Ron Hitchens    University of Texas at Austin, Computer Science
  124. hitchens@uo.cs.utexas.edu
  125. hitchens@sally.UUCP
  126.