Hi, On Fri, 19 May 2006, Andre Wobst wrote:
> Hi, > > On 12.05.06, Arnd Baecker wrote: > > On Fri, 12 May 2006, Andre Wobst wrote: > > > > [...] > > > > > 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. > > > > Very very nice detective work - amazing! > > But in the end I could not find anything. And for some days I thought > that the solution with binascii=2 might not really solve the problem > either: After my analysis of the communication between gv and gs I > expected that it's some internal problem with passing the input to gs. > Why shouldn't a similar problem occur for ASCIIHexDecode for some > other situations? > > Well, my mind was changed: I've tried the latest gs-8.54 (from > Wednesday ... I'm still missing the freshmeat announcement ... :-)) > and the issue seems to have been addressed and resolved. See > http://bugs.ghostscript.com/show_bug.cgi?id=688618 That's good! > Here we also learn, that the problem arises at the end of parsing a > ASCII85 encoded stream. And after knowing that, I tried again to > reproduce the problem without using gv again. Here it we are: > > [EMAIL PROTECTED]:~/src$ python -c 'print > open("pyx_embed_prob.ps").read()[314256:][:136768].replace("\n", " ", > 2)[:-523]'|ghostscript-8.53/bin/gs - > AFPL Ghostscript 8.53 (2005-10-20) > Copyright (C) 2005 artofcode LLC, Benicia, CA. All rights reserved. > This software comes with NO WARRANTY: see the file PUBLIC for details. > Error: /undefined in ~ > Operand stack: > > Execution stack: > %interp_exit .runexec2 --nostringval-- --nostringval-- > --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- > --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 > %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 > --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push > --nostringval-- > Dictionary stack: > --dict:1117/1686(ro)(G)-- --dict:0/20(G)-- --dict:73/200(L)-- > Current allocation mode is local > AFPL Ghostscript 8.53: Unrecoverable error, exit code 1 > Traceback (most recent call last): > File "<string>", line 1, in ? > IOError: [Errno 32] Broken pipe > [EMAIL PROTECTED]:~/src$ python -c 'print > open("pyx_embed_prob.ps").read()[314256:][:136768].replace("\n", " ", > 2)[:-523]'|ghostscript-8.54/bin/gs - > AFPL Ghostscript 8.54 (2006-05-17) > Copyright (C) 2005 artofcode LLC, Benicia, CA. All rights reserved. > This software comes with NO WARRANTY: see the file PUBLIC for details. > > The replacement of the newlines (without changing the number of bytes) > and cutting of the last 523 bytes is just to make the file valid > PostScript without the setup done by other parts of the orginial > file which gv somewho sends separately and than resets the gs input > stream. And since I didn't did those resets, I couldn't reproduce the > error myself by my python script I posted about a week ago. > > In the end we could have seen the problem much earlier: The tilde is > the end character of an ASCII85 encoded stream ... bang. > > And Arnd, you told me some time ago when we meet in Dresden, that you > frequently step into this problem. There is a simple reason for that: > your plots frequently insert small bitmaps, where ASCII85 encoded > streams occur each time. Sooner or later you'll get step into that > ghostscript bug. So this bug will be with us for a while until everyone runs the latest ghostscript.... > BTW: Why don't you use larger bitmaps (covering the > whole graph)? Even when you than need to add the bitmap data for all > the white area (and as long as you don't need that area to be > transparent), I expect this to be much smaller in the result and > faster too! Sorry, but I don't understand - A couple of plots I have look (in principle) like: http://www.physik.tu-dresden.de/~baecker/python/pyxgraph/array1.png Internally the bitmap is obtained from a PIL array via im = Image.new("RGB",(w,h)) im.fromstring(rgb.tostring()) where rgb is an (N, 3) arrray with the r, g, b colors. How would using a larger bitmap avoid the ASCII85 encoded streams? > Beside that I'm thinking about removing the ASCIIHexDecode again. It's > a quick hack and only implemented for current stream binary inserts > (not for storring data on the PS stack and for the palette of indexed > images). We should either remove it once and for all or implement it > properly. I strong +1 for removing it ... :-) So what is the alternative to ASCIIHexDecode when one has ghostscript < 8.54? Many thanks, Arnd ------------------------------------------------------- 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
