postscript from Symbolics to a laserwriter via a Sun
King Ables
ables at hi3.aca.mcc.com.UUCP
Thu Apr 28 05:21:30 AEST 1988
As promised, here are (possibly edited versions of) the replies I got
to my Symbolics to laserwriter via Sun printing problem query. Any
editing was done to remove incorrect or misleading information
(I say "incorrect" based on my observation of conflicting behavior).
However, almost all the information was correct and very valuable.
Thanks to those who responded. I wound up trying the first
solution of simply changing the %!PS-Adobe-0.67 that was in the
preamble of the Postscript file generated on the Symbolics machine
to simply %!PS instead. This no longer made it claim to be "real-
honest-to-God-perfect" Postscript. Because of this, the Sun spooling
software didn't want to take a chance on reversing it so it didn't
run psrv (which is how FrameMaker does it) so it came out correctly.
I imagine we'll hack our Symbolics and modify the Postscript preamble.
-king
ARPA: ables at mcc.com
UUCP: {gatech,ihnp4,nbires,seismo,ucb-vax}!ut-sally!im4u!milano!ables
---------------------------------
Date: Sat, 23 Apr 88 19:45:44 PDT
Subject: Re: page reversal problem
The "psrv" filter identifies a conforming file by looking at the
first line. If it matches "%!PS-Adobe-" (plus version numbers or
whatever might follow) it is assumed to be page-reversible. Frame
Maker omits the "PS-Adobe" part, which means that it does not claim
to be a conforming document. In fact, their documents are, and you
could fix the prolog (.makerinit/ps_prolog, or something) to have
the full "%!PS-Adobe-2.0" comment, and the pages should reverse fine.
As for the other output not working correctly, It is probably the
PostScript file itself that is not really page-reversible. "psrv"
uses the %%EndProlog and the %%Page comments to decide how to
reverse the code. You can, I think, run it directly, and see what
happens to the file:
psrv < infile > outfile (possibly different calling seq.)
And look at the two files to see what happened. If the file looks OK
but still doesn't print right, there may be some interdependencies
between the code in page 1, and the code in page 2 which cause it
not to work properly when the chunks are physically rearranged.
If you cannot fix it by, say, moving the %%EndProlog comment or
something simple, you can defeat the page reversal simply by
changing the first line comment, as Frame did.
I hope this helps.
Glenn REid
Adobe Systems
----------------------------
Date: Sun, 24 Apr 88 19:18:34 EDT
From: Yoram Eisenstadter <yoram at cheshire.columbia.edu>
Subject: Re: postscript from Symbolics to a laserwriter via a Sun
The way paging works in Postscript is that the application which
generates the postscript puts in so called "structure comments"
which are comments to Postscript but get looked at by the various
programs which manipulate Postscript code (e.g., psrev, the page
reversal/selection program). The comments which delimit pages
look something like "%%Page NN". What psrev essentially does is
to yank out the desired pages in the desired order, looking at
the %%Page comments to see where pages begin and end. It then
takes these desired pages, prepends the prologue of the postscript
file, appends the epilog of the postscript file, and the result
is a new postscript file. So far, very simple.
Certain structure comments must be present and various conditions
must hold in order for the PS-generating application to be
"compliant" with the Postscript conventions. There are two
versions of conventions currently used; the structure comment at
the top of the postscript file must be present to specify that
the file satisfies a given set of conventions (this line looks
something like: "%!PS-Adobe-N.N", where N.N is 1.0 or 2.0).
One of the most important conditions for compliance is that each
page consist of totally state-independent postscript code, so
that things don't get screwed up when you reverse pages or print
only random pages. Thus, all definitions which are to be used on
more than one page have to be made in the prologue section of the
postscript file.
The facts that your file (1) makes it to the Sun spooler intact,
and (2) prints properly when not run through psrev, strongly
suggest that the 7.2 Symbolics software violates the postscript
file structuring conventions which psrev expects; most probably
the problem is non-independence of pages. The fact that your
other postscript-based stuff works properly is also evidence of
this.
Cheers..Y
--
Yoram Eisenstadter | ARPAnet: yoram at cheshire.columbia.edu
Columbia University | UUCP: [rutgers!]columbia!cheshire!yoram
450 Computer Science Bldg. | uunet!cheshire.columbia.edu!yoram
500 West 120th Street | Bitnet: yoram at cucsvm
New York, NY 10027 | Phone: (212) 280-8180
---------------------------
Date: Mon, 25 Apr 88 17:56:22 EDT
From: lou at aramis.rutgers.edu (Lou Steinberg)
Subject: Re: postscript from Symbolics to a laserwriter via a Sun
Here's a hack to try: to fool psrev into thinking the file is all one
long page, try a string substitution of replacing all strings of the
form "%%page" with %%%page". An alternative is to make psrev think
the file is not in a format it understands: delete the characters
"-1.0" from the end of the first line of the file.
--
Lou Steinberg
uucp: {pretty much any major site}!rutgers!aramis.rutgers.edu!lou
arpa: lou at aramis.rutgers.edu
More information about the Comp.unix.wizards
mailing list