weening@GANG-OF-FOUR.STANFORD.EDU (Joe Weening) (09/12/89)
I'm trying to bring up Ghostscript 1.3 using X11 on an Alliant running Concentrix 5.0 (4.3 BSD-derived), and can't seem to get off the ground. Has anyone fixed problems since 1.3 was released? Sorry I haven't paid attention to this list/newsgroup in the last few months. -- Joe Weening Computer Science Dept. weening@Gang-of-Four.Stanford.EDU Stanford University
pete@relay.nixctc.de (Pete Delaney) (10/10/89)
I tried installing Ghostscript 1.3 on a Sun 3/160 that I installed X11R3 on.
I seem to have the same problem as mentioned in Lee McLoughlin's July 3
article " Patches for ghostscript-1.3 for BSD":
Here are some patches I needed to get gs working on a 4.2 BSD system.
It still doesn't work fully. On doing
./gs leta.ps
It creates an inital window. When I hit return it then creates
another window. On hitting return again it then draws in
the second window!
I've not yet looked into this problem.
Lee
Ps: Where did all the example postscript files go? I had them around
but without them how are you supposed to test gs?
I installed his patches and am now in the same state, gs blocks, perhaps
waiting for a chartacter due to a X11 bug, and puts up two windows.
Commands entered to the interpreter don't seem to be working. Data
entered to the operand stack doesn't seem tpo stay on the stack. For
example:
GS> 1
GS> 1
GS> add
results is a stack underflow, it seems because the operands are not
put on the stack. With tracing enabled the debug output looks like:
Reading ghost.ps... ghost.ps read.
Ghostscript 1.3
GS>
GS>clear
GS>1
GS>
Interp returns 0
ostack:
67220: 5 int ---------- a7d8 1
2
GS>
Interp returns 0
ostack:
67220: 5 int ---------- a7d8 2
3
GS>
Interp returns 0
ostack:
67220: 5 int ---------- a7d8 3
dup
Error: /stackunderflow in --nostringval--
ostack:
estack: operator 455e --nostingval-- --nostringval-- --nostringval
-- false -
-nostringval--
dstack: 276/300 2/200
GS>1 2 add
GS>
Interp returns 0
ostack:
67220: 5 int ---------- a7d8 3
Another interesting thing is BadLength on a poly request in Xlib when passing
a postscript file to the interpreter:
GS> (test.ps) run
this results is the following
(test.ps) run
X Protocol error: BadLength, poly request too large or internal Xlib
length err
or
Major opcode of failed request: 1 (X_CreateWindow)
Minor opcode of failed request: 0
Resource id in failed request: 0x40000004
Serial number of failed request: 621
Current serial number in output stream: 1150
Before investigating further I thought a friendly hacker on the net might
have a simple suggestion that could save me some time.
==============================================================================
Pete Delaney - Nixdorf UCC | pete@nixctc.de Prefered Addr
Loffel Strasse 3 | pyramid!nixctc!pete UUCP from Calf
7000 Stuttgart 70 | unido!nixctc!pete UUCP from uunet
West Germany | Phone: +49 (711) 7685-128