Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!asuvax!noao!ncar!mephisto!purdue!haven!umd5!zben
From: zben@umd5.umd.edu (Ben Cranston)
Newsgroups: comp.lang.postscript
Subject: Re: Question about Concatenating PS Files
Summary: Here's a real-life example
Message-ID: <6786@umd5.umd.edu>
Date: 29 Jun 90 17:43:06 GMT
References: <138052@sun.Eng.Sun.COM>
Reply-To: zben@umd5.umd.edu (Ben Cranston)
Distribution: usa
Organization: University of Maryland, College Park
Lines: 67

In article <138052@sun.Eng.Sun.COM> grantw@zooid.Eng.Sun.COM 
(Grant Williamson) writes:

> I want to take an arbitary number of PostScript files and concatenate 
> them together for subsequent processing by various PostScript programs.

Yes, I know the guy explicitly asked for email, and in fact I typed this
entire message in as an email message, but as I was about to commit it I
thought that the concept of PostScript save is something that everybody
could profit from.  So, I killed the mailer and am posting it instead.
Mea culpa.

Here's something I wrote that handles a real worst case scenario, multiple
Macintosh command-f files!  I did multiple technical notes with it.

#! /bin/sh

# output file both sides
# m option for macintosh files

{ case "$1" in
-m|-M) cat $HOME/etc/ratpro70 ; shift ;;
*) echo %!PS-Adobe ;;
esac

echo statusdict begin true setduplexmode end
for file in $*
do
        echo save mark
        cat $file
        echo cleartomark restore statusdict begin newsheet end
done
} | qpr -q lps20

You can ignore the setduplexmode stuff, that was to print on both sides
of the paper.  The important stuff is the stuff in the do loop.  It saves
the state before each file and puts a mark on the stack.  After the file
it clears the stack back to that mark and does a restore of the save object.
The statusdict begin newsheet end gets each new file on a new physical
piece of paper, again, this is the bothsides stuff.

A malevolent file can still kill this by clearing away the mark and the
stacked save object, but Mac files don't do this.  They do leave detrius
on the stack, though, hence the mark/cleartomark stuff.

If you are really paranoid you could save the save object under some name
and get it back, with something like this:

/bandersnitch save def
   <.include file 1 here.>
bandersnitch restore
/bandersnitch save def
   <.include file 2 here.>
bandersnitch restore

and so on.  Then only if the included files blow away the bandersnitch
variable would it break.

You could probably protect against even that by creating a directory and
putting it on the directory stack before including the file.  Then any use
of the name would occur in that directory, and you could pop it off when
you get back from the include file...
-- 

Ben Cranston <zben@umd2.umd.edu>
Warm and Fuzzy Networking Group, Egregious State University
My cat is named "Perpetually Hungry Autonomous Carbon Unit"; I call him "Sam".