Hi Alex, thanks for that tip. Unfortunately, it does not work for me. I tried the -dNOCACHE option the way you described and the resulting files were all bigger in size than the original ones by a factor of 3 to 6. Neither eps->eps->pdf, eps->pdf, nor pdf->pdf did reduce the file size. And another thing, that might be uncritical for 2d plots, is the display speed of the ghostscripted files. One can virtually watch every single line of the 3d plot being drawn (same in Acrobat Reader, ggv, and xpdf, so I suppose this is an issue of the file and not of the viewer). This is very annoying for an electronic paper that one might want to read on the screen. I did not check what the -dNOCACHE option is really doing to the files, but it is probably not doing what I am looking for.
Thanks anyway. Benedikt Am Mittwoch, den 14.05.2008, 10:01 +0200 schrieb Axel Freyn: > Hi Benedikt, > > for me also file size is the big disadvantage of some pyx plots: I > was doing some plots like > http://pyx.sourceforge.net/gallery/graphs/mandel.html, which really > became enormous files of a few hundred MB; There, it is possible to > solve the problem by directly creating bitmaps in pyx instead of using > graph.graphxy(), but for 3d images this wan't be a solution, I think. > > After some try and error, I also found another solution: You can > postprocess the files with ghostscript to reduce the filesize - > keeping fonts as vector fonts: for me, this works with the option - > dNOCACHE, even if I don't know why (man gs states: > -dNOCACHE > Disables character caching. Useful only for debugging. > ). > > gs -q -dNOCACHE -dBATCH -dNOPAUSE -sDEVICE=epswrite - > sOutputFile=out.eps in.eps > > BUT: the strange thing is: if you do this, the BoundingBox is not > calculated correctly: characters are ignored in determining the > BoundingBox... So, after the conversion, you need another > gs -sDEVICE=bbox out.eps > to determine the BoundingBox, which you then can include into the > output-file (exchanging the 2 and 3 line) > > HTH, > > Axel > > > On Thu, May 8, 2008 at 10:35 AM, Benedikt Koenig <[EMAIL PROTECTED]> > wrote: > Hi All, > > I have a problem concerning the file size of my plots. > Producing 3d > graphs of my data leads to single PDF files of several MB > size. > Including these graphs in my paper gives a nice to print > document, but > it is way to big for easy electronic distribution as PDF. So I > was > thinking if there is a way to produce these high quality > vector graphics > for the print version of the paper but to somehow get some > smaller sized > graph files for the electronic version. > > Currently I am limiting the size by plotting only every x-th > point. But > obviously this is a stupid solution if you are lucky enough to > have high > resolution data in the first place. Alternatively I could use > pipeGS to > produce bitmaps of the complete graph, but I'd rather keep the > axes and > text as vectors and only have the actual data as bitmap. > > My idea is basically to produce the highly resolved 3d graph, > then > convert the plotted data into a bitmap while keeping axes and > text in > vector format and then write the whole stuff to a PDF. This > should keep > file sizes moderate even if the bitmap has printing quality of > around > 300 dpi. > > Are there any opinions on whether some thing like this is > possible at > all using PyX and if yes, how to do it? Or is there any other > way to > keep file size small for complexe plots? > > Thanks already, > bene > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) > Conference > Don't miss this year's exciting event. There's still time to > save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p? > http://java.sun.com/javaone > _______________________________________________ > PyX-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/pyx-user > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ PyX-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pyx-user
