When creating a png with the pngalpha device, the background is not completely transparent in a large area around the drawn components of the PDF. This is clearly wrong as the resulted png should be transparent in all areas where the PDF does not draw anything. The non-transparent areas seems to become smaller with a larger resolution. But it requires a really high DPI (1000+) to remove it almost completely. We use the following example command line options to create our pngs gs -dNOPAUSE -dBATCH -dUseCropBox -dSAFER -dEPSCrop -dFirstPage=1 -dLastPage=1 -sDEVICE=pngalpha -dGraphicsAlphaBits=4 -dTextAlphaBits=4 -r68.459015 -sOutputFile=output.png -f input.pdf Seems to be related to bug 693024.
Created attachment 10703 [details] PDF test case created with InDesign CS6 PDF Testcase
Created attachment 10704 [details] PNG result created with ghostscript PNG created with ghostscript from PDF testcase. If opened with preview on Mac to see the transparent background, there are white boxes in areas around the rectangles
This also only happens when the PDF has transparent elements in it. If all rectangles have an opacity of 100 in InDesign no white areas around them show up.
This is a known limitation. The file has PDF transparency operations in it. As a result the first thing the pngalpha device sees is the "image" which is the result of the blending operations occurring in the page group. As it implies, the page group covers the entire page, thus, as far as the pngalpha device is concerned the entire page is marked, hence there is no "background" visible to be transparent. Likely the behaviour with higher resolutions is due to the page being rendered in bands. In order to render in bands, we first accumulate a "command list" (clist) of graphics primitive operations which we can "replay" multiple times, once for each band. During clist accumulation, we can record where in the page group actual transparent marks occur, and on the clist playback, only apply transparency blending in those bands. Lower resolutions don't use the clist, so we don't have an advance record of the area(s) covered by transparency. Improving that may be possible, but would be an enhancement.
So you are saying that in the current state ghostscript cannot be be trusted to create a png with a full transparent background and we should look for other tools? We rely on the png being fully transparent in areas without drawing operations because we then go on and use it in painting operations within our system which might have other elements in the area. These elements are now not shown because the png blocks them out, which is unacceptable for us.
(In reply to comment #5) > So you are saying that in the current state ghostscript cannot be be trusted > to create a png with a full transparent background and we should look for > other tools? Unfortunately, that is currently true - the limitation is documented in Devices.htm The architectural changes to allow this to work correctly have been done, but the changes to the device have not been undertaken as yet. > We rely on the png being fully transparent in areas without drawing > operations because we then go on and use it in painting operations within > our system which might have other elements in the area. These elements are > now not shown because the png blocks them out, which is unacceptable for us. If you can give us a day or two, I will nudge my colleagues in the US (this is more their area of expertise), and we can see how much work would be involved in implementing the functionality in the device. The enhancement is already being tracked under another number, so I have marked this as a duplicate, and added your customer number to the original report. *** This bug has been marked as a duplicate of bug 687630 ***
Thanks, i'll wait to see how big of a change this is for you.
In order for this to work for the pngalpha device, this device must implement a 'pdf14_put_image' procedure that is able to accept the planar data that includes the alpha for each pixel. For general devices, the "default" put_image will have to emit an ImageType 3 that has a mask (at least for the areas that have alpha == 0) and show the blended RGB colors on the "marked" areas.
Thanks for the answer. Do you have any timeframe for when this functionality can be implemented/released at this point? We have a hard release sometime in March, so need to know if we will need a temporarily solution until Ghostscript supports this.
This has been fixed by commit: 174cfd1 Fix pngalpha when PDF has transparency. Bugs 687630, 693024 and 695042.