I've used GS 8.63 for some months and everything went almost perfect but at one moment I had a problem with some EPSes and I decided to update to GS 8.64. Since then all EPSes that I have with some transparency on the interior doesn't convert correctly to PNG - instead of transparency, I get a white zone. I'm using the following command line C:\GS\gs8.64\bin>gswin32c -dSAFER -dBATCH -dNOPAUSE -r300 -sDEVICE=pngalpha - dTextAlphaBits=4 -dGraphicsAlphaBits=4 -sOutputFile=Temp_3001.png -dEPSCrop goala.eps Please check the attached files as examples for EPS.
Created attachment 5066 [details] EPS with transparency - example 1
Created attachment 5067 [details] EPS with transparency - example 2
I'm using the Windows Vista 32bit.
I was able to duplicate this and found the revision responsible for the regression: ------------------------------------------------------------------------ r9288 | leonardo | 2008-12-13 12:05:37 -0800 (Sat, 13 Dec 2008) | 26 lines Enhancement (graphics) : Implement new device virtual method 'fillpage'.
Please, help me somehow to get a fix for this? What possibilities do I have? Thank you
We'll have a discussion at Tuesday's meeting about reverting this fillpage patch.
fix severity.
I see difference in file 'example 1' between gs 8.63 and gs 8.64, but do not in 'example 2'. I tried 'example 1' with current head (r9980) and reproduced the problem on both Mac OS X 10.5.7 + Xcode 3.1.2 and Windows XP SP3 + VS2008 Express SP1.
I can confirm that the same occurs for ps2pdf conversion. A white background is added for transparent ps files. This is crucial for personalization when merging generated PDF files with master pages. This white background covers whole master page. This makes personalization impossible.
Hi, I've seen that a new release has been made (8.71) but though I'm applying it, it doesn't seems to fix my problem. Has been done something lately about this bug? Thanks.
I will look into this soon (within the next few weeks).
*** Bug 691957 has been marked as a duplicate of this bug. ***
Are you sure that this is the same bug (691957) ? I just try the release 8.63, and I have the same result with an .ai (si this is not a regression since 8.64 in my case).
We run into this problem a lot at Pixar. The problem occurs when the image is larger than BitmapMax. A workaround is to set BitmapMax on the command line. The default is 10M we have been experimenting with setting it to 2G. Chris King Technical Director Pixar Animation Studios
OK, so this problem is only with clist (banding) mode. The correct spelling of the parameter that controls the maximum page size that will use page buffer mode is -dMaxBitmap= I determined that with -dMaxBitmap=13000000 is large enough with this file (when using -dEPSCrop) to avoid using banding mode so that the center of the page frame is transparent in the pngalpha output. Assigning to myself to see why clist mode is not acting the same way as page buffer mode.
Ghostscript v. 9.06 preserves transparent background in both files with any value of -dMaxBitmap= , including rather small ones. The command line given in the original report also works fine.
I've reopened this bug since differences between the page mode and clist mode shouldn't exist: (In reply to comment #15) > Assigning to myself to see why clist mode is not acting the same way as > page buffer mode.
As per my email to tech "banding/page mode bugs", closing this file as I cannot reproduce a problem.