Hi,
On 12.05.06, Arnd Baecker wrote:
> Still, the whole issue seems really weird, in particular
> because small changes in the text part of the latex file
> can make the problem disappear even without the PSbinexpand.
>
> So can one say that this is a bug in gv?
> Interestingly/sadly, it does not show with the .eps alone,
> but only when embedded...
> It would be nice to have a simpler way to trigger the bug...
> I had a look at the gv project at
> http://www.gnu.org/software/gv/
> http://savannah.gnu.org/projects/gv
> and the activity is pretty low, in particular
> wrt replies to bug reports and questions which
> is not very encouraging to file a bug report there ...
Well, I tried to find out what's going on here, but so far its
becoming more and more complicated. First I compiled gv myself and
started adding debug code to understand what happens. And thereby I
learned that gv tries to send the proper code to ghostview. More
precisely it does something like this:
import os, threading
class read(threading.Thread):
def __init__(self, pipe):
threading.Thread.__init__(self)
self.setDaemon(1)
self.pipe = pipe
self.start()
def run(self):
while 1:
line = self.pipe.readline().strip()
if line:
print line
data = open("pyx_embed_prob.ps").read()
input, output, error = os.popen3("gs -")
read(output)
def write(position, length):
while length > 512:
input.write(data[position: position+512])
position += 512
length -= 512
input.write(data[position: position+length])
write(306, 172095)
write(172401, 89)
write(172490, 58589)
write(231079, 83177)
write(314256, 136768)
The numbers in the write commands fit to the "pyx_embed_prob.ps"
posted by Arnd. And the write command is split into 512 byte blocks to
overcome some kind of blocking (AFAIK gv doesn't use threads as I do
here and thus its crucial to ensure, that the write commands don't
block and result in a deadlock -- hence they use fractions which fit
into the pipe buffer such that the write doesn't block).
However in ghostview the while-loop in write is more complicated.
Other messages going around in the system are catched as well, and at
a ceratin point the xclient.message_type becomes
XmuInternAtom(XtDisplay(w),gvc->ghostview_class.done) and than gv
stops to pass things to ghostscript. At that point it seems to be
already to late. But the strange thing is (as far as I understand
what's going on) that ghostscript indeed sends such a kind of
interprocess DONE mark, namely by the statement
gdev_x_send_event(xdev, xdev->DONE) in gdevxini.c. I've tried to find
out why this event is created, but I found out (by a backtrace of this
call in ghostscript when started by ghostview) that it happens due to
the gs_closedevice call in the gs_main_finit function of imain.c. And
this call seems to occur at a point where the whole interpreter
already stopped. So somehow ghostscript seems to stop due to some
(internal?) error before all the PostScript code is send by ghostview.
I'm giving up ... I really don't understand, what's going on here.
André
--
by _ _ _ Dr. André Wobst
/ \ \ / ) [EMAIL PROTECTED], http://www.wobsta.de/
/ _ \ \/\/ / PyX - High quality PostScript and PDF figures
(_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
PyX-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pyx-user
