Created attachment 13642 [details] faulting pdf Following command to render a white PDF into a black image: gs -dNOPAUSE -dBATCH -dQUIET -dNOPAGEPROMPT -sDEVICE=png16m -dGraphicsAlphaBits=4 -r100 -dFirstPage=1 -dLastPage=1 -sOutputFile=output.png >/dev/null 2>&1 white_black.pdf
Created attachment 13643 [details] modified file This is caused by using GraphicsAlphaBits=4 and the construction of the PDF file. Note that the file does not contain any images, so this is not an 'images' problem. All the content is linework (vector shapes). All the objects are drawn using a graphics state with a constant alpha (ca) of 0, ie totally transparent, makes no marks, which is the only reason that the page is white. I've attached a version of the file where the constant alpha has been removed, you can see this is very similar to the result when GraphicsAlphaBits is 4. In short, GraphicsALphaBits (which long predates the presence of PDF transparency) cannot be relied upon when rendering transparent PDF files, because it operates in a way incompatible with the blending of PDF transparency. I've assigned this to our transparency expert to see (as a low priority) if there's any way to address this, but I strongly suspect the answer is no. So don't use GraphicsAlphaBits (or TextAlphaBits) with transparent PDF files. If you want anti-aliasing for some reason, use the *scaled devices.
This should actually work fine. The gdevabuf device does a copy_alpha call when its alpha buffer is to be flushed which ends up in pdf14_copy_alpha. The file renders properly in the non-clist case. Going through the clist, the file renders wrong. Transfering the bug to Ray to have a look.
The bug is reproduced in the current master branch on GNU/Linux and Android platforms.
Michael's comment is not correct as far a I can tell. I get the same output (Black background with 6 white "dots" along the bottom lower left) from clist and non-clist: gswin64c -dGraphicsAlphaBits=4 -sDEVICE=ppmraw -o pagemode.ppm -Z: faulting.pdf and gswin64c -dMaxBitmap=2g -dGraphicsAlphaBits=4 -sDEVICE=ppmraw -o clist.ppm -Z: faulting.pdf (and both give the all white page without -dGraphicsAlphaBits=4) I'd like Michael to look at what might be going on with non-clist mode, taking into account Ken's comment that it may not be fixable. Then if there is still a clist mode difference I'll look into it.