On Mon, 22 May 2006, Andre Wobst wrote: > Hi, > > On 22.05.06, Arnd Baecker wrote: > > > 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? > > It would not avoid ASCII85 encoded streams. But although the bug seems > to be in ghostscript for a long time already, it seems to be triggered > in rare cases only. It just has been identified and fixed recently. > But from what you've told me you stepped into the problem frequently. > While this is not a problem at all, it is related to how you build > your output. There's nothing wrong in building a lot of small bitmaps > -- but larger bitmaps (even when most parts might be white) may still > help you to further reduce your file size (and the rendering will > probably also become faster). > This was just a comment I wanted to make > about why I guess you've seen the issue that frequently.
I think that this is more an effect of statistics - for example if I generate a file with 3626 plots (of Husimi functions of a quantum map - FWIW), then chances get pretty high that I will run into the problem. > > > 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? > > What a question. Well, I just wanted to be sure that I don't miss a possible alternative ;-) > The alternative is to update ghostscript to a > version, which doesn't show the bug ... :-) Hmm, this might be an option for my own computer, and maybe one (though with more effort ;-) for all the machines in our group. However, I clearly cannot upgrade ghostscript on any of the computers of potential readers of my articles. So therefore I would conclude that there is no alternative to ASCIIHexDecode... > The point is that we currently do not support the PSbinascii flag very > well ... it's a hack (beside that it's not documented etc.) and we > should get rid of it again ASAP (as we do now understand what was > going wrong and since a proper solution). OTOH, this seems the only solution to the original problem as long as one cannot be sure that all readers will have ghostscript>=8.54, so I am not so positive on removing it. Best, 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
