ables@hi3.aca.mcc.com.UUCP (King Ables) (04/23/88)
We've had an interesting problem with our Symbolics machines lately.
I've cross-posted this to the three groups where people might have
seen this problem before.
We have a laserwriter hooked to a Sun-3 server to which all of our
Unix machines can spool. We have a Vax-11/750 running Mt. Xinu 4.3
with Chaos hacked into it. We have a bunch of Symbolics machines in
addition to our Unix machines. Some of the Symbolics are running
Genera 7.1 and some are running 7.2.
Under 7.1, people could do a hardcopy to the laserwriter which
generated postscript, sent it to the Vax via chaos, who in turn
queued it to the Sun-3 for printing on the laserwriter and all
worked well.
Under 7.2, the same process takes place, but when the output is
printed, only the first two pages are printed. The rest of the
output is gone.
We've been able to trace the postscript to the Sun server
and it is still intact (i.e. in the same condition as it
was generated by the Symbolics machine). We have determined
that sometime during the actual sending to the laserwriter is
where things get hosed. Specifically, it seems that the Transcript
filter psrv is doing something bad.
The Symbolics machine reverses the pages of the output when
generating the postscript. So, for example, in a 3-page document,
if you look at the postscript generated by the Symbolics host,
you see the pages in 3,2,1 order. Since everything else needs
to have pages reversed, the laserwriter filters use psrv to
reverse the pages again (for lpr, ptroff, etc.). We have found
that if we bypass the psrv filter, the output will come out correctly.
But then, of course, ptroff and lpr output comes out backwards.
Interestingly enough, output from FrameMaker comes out correctly
regardless of whether or not we are bypassing the psrv filter!!
So, after all this, I have two questions...
1) has anybody seen this behavior before or know what might
cause it? We can't even decide where to lay blame (whether
it really is something wrong with psrv in the Transcript
software from Sun, for which we of course don't have the
source or whether the Symbolics is generating slightly
bad postscript code which as long as it isn't moved around
happens to work but when things are rearranged doesn't work
anymore.
2) Does anybody know why FrameMaker output DOESN'T get
reversed when bypassing the psrv filter? If there is
something that can be put into the postscript to ignore
pagereversal, then perhaps we could just put that in on
the Symbolics side and the problem would be fixed.
I am very hesitant to hack a fix into something before I know
who is really doing the "wrong" thing. I'd like to fix what
is wrong, not patch what is right for a special case of something
that is broken.
I would appreciate replies directly to me and I will, of course,
summarize.... comp.unix.wizards is the only one of the three groups
this message is heading towards that I read.
Thanks for any info.
-king
ARPA: ables@mcc.com
UUCP: {gatech,ihnp4,nbires,seismo,ucb-vax}!ut-sally!im4u!milano!ablesables@hi3.aca.mcc.com.UUCP (King Ables) (04/28/88)
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@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@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@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@cucsvm
New York, NY 10027 | Phone: (212) 280-8180
---------------------------
Date: Mon, 25 Apr 88 17:56:22 EDT
From: lou@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@aramis.rutgers.edu