gs breaks on its own sample file ~/ghostpdl/debugbin/gs -q -sDEVICE=x11 -dNOSAFER examples/transparency_example.ps X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 70 (X_PolyFillRectangle) Resource id in failed request: 0x7600003 Serial number of failed request: 19 Current serial number in output stream: 23 Rendering to the pdfwrite device drops transparency. Rendering to raster devices works fine.
*** Bug 702218 has been marked as a duplicate of this bug. ***
As was probably predictablle, the commit that introduced this was the fill+stroke commit: 05c41c0dedaa512419f15798cbc3da92b6a90bbc I'm assigning this to Michael because (I think) he rewrote the section of pdfwrite which deals with alpha. In gdevpdfg.c, pdf_update_alpha() at around line 2908. Essentially I believe this is fallout from the ongoing movement of the various PDF graphics state parameters from PostScript into C. The code now looks at the separate stroke and fill constant alpha values in the graphics state, but the .setopacityalpha operator ends up in gs_setopacityalpha() (in gstrans.c) which does this: pgs->opacity.alpha = (alpha < 0.0 ? 0.0 : alpha > 1.0 ? 1.0 : alpha); Since the pdfwrite code is no longer checking the value of opacity.alpha in the graphics state it doesn't write out a changed value, and so there appears to be no transparency in the PDF file. In fact there is, we do create a group, but that's all. I see that the PDF interpreter still calls .setopacityalpha, and there are places in the C code which still set and reset it, but I admit these look vestigial. Its possible we should no longer be using .setopacityalpha but that's not clear to me. In pdf_draw.ps whenever we call .setopacityalpha we generally call the PDF CA operator as well, and when we call .setshapealpha we generally call the PDF ca operator. The exceptions are annotations where we generally don't do this, but transparent annotations are rare so faults wouldn't be seen. This was done when I added CA and ca to the grapchis state, in order to properly track those values when they were set by our internal actions, using .setopacityalpha. Adding these lines to gs_setopacityalpha() : pgs->fillconstantalpha = (alpha < 0.0 ? 0.0 : alpha > 1.0 ? 1.0 : alpha); pgs->strokeconstantalpha = (alpha < 0.0 ? 0.0 : alpha > 1.0 ? 1.0 : alpha); results in a working PDF file, but since I don't really know if there's any intention that we should preserve the graphics state 'opacity' in addition to the separate PDF graphics state parameters I'm not going to commit this as a 'fix', I think I need Michael to look into this. Later note; I tried setting either fill or stroke alpha when setopacityalpha is set and it causes hundreds of diffs on the cluster, so clearly this isn't a solution.
Fixed issue with PDFWrite with https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=d12d2085b5bd08ca1e813d97f3f7f7e630e791a0 will take a look at X11 device after the weekend.
This (the removal of setopacityalpha and setshapealpha and their replacement by setfillconstantalpha and setstrokeconstantalpha) are significant changes for the TeX community, given that two very popular packages, pstricks and PGF/TikZ, implement transparency via setopacityalpha (namely, they prepare a PS file including .setopacityalpha and apply ps2pdf to it). I have posted a message to the tex-live mailing list, at <https://tug.org/pipermail/tex-live/>, so that the developers there are aware of the issue, can prepare for the change and get in touch with you if need be.
This issue has been addressed. Those methods are now deprecated.