Bug 695048

Summary:	Alpha PNG created from PDF with pngalpha does not give a complete transparent background
Product:	Ghostscript	Reporter:	Søren Chrestensen <soc>
Component:	Other Driver	Assignee:	Default assignee <ghostpdl-bugs>
Status:	NOTIFIED DUPLICATE
Severity:	enhancement	CC:	chris.liddell
Priority:	P4
Version:	master
Hardware:	PC
OS:	Linux
Customer:	200	Word Size:	---
Attachments:	PDF test case created with InDesign CS6 PNG result created with ghostscript

Description Søren Chrestensen 2014-02-17 02:23:47 UTC

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.

Comment 1 Søren Chrestensen 2014-02-17 02:24:36 UTC

Created attachment 10703 [details]
PDF test case created with InDesign CS6

PDF Testcase

Comment 2 Søren Chrestensen 2014-02-17 02:26:20 UTC

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

Comment 3 Søren Chrestensen 2014-02-17 02:27:33 UTC

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.

Comment 4 Chris Liddell (chrisl) 2014-02-17 02:36:52 UTC

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.

Comment 5 Søren Chrestensen 2014-02-17 03:05:21 UTC

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.

Comment 6 Chris Liddell (chrisl) 2014-02-17 03:19:54 UTC

(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 ***

Comment 7 Søren Chrestensen 2014-02-17 03:38:34 UTC

Thanks, i'll wait to see how big of a change this is for you.

Comment 8 Ray Johnston 2014-02-17 19:52:59 UTC

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.

Comment 9 Søren Chrestensen 2014-02-19 01:39:57 UTC

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.

Comment 10 Ray Johnston 2014-02-19 07:16:15 UTC

This has been fixed by commit: 174cfd1
   Fix pngalpha when PDF has transparency. Bugs 687630, 693024 and 695042.