Created attachment 18989 [details] example file for transparency testing Current Ghostscript doesn't allow transparency operations. None of -dNOSAFER and -dALLOWPSTRANSPARENCY options is effective. An example file for testing is attached.
I tried this file with 9.27 and the most recent 9.51 release. Both look the same (without more information). 9.27 does not default to -dSAFER. Also from examination of the file, there is no usage of the Ghostscript PS transparency extensions. Also this looks the same as the output from Adobe Acrobat 9 Professional which can open PS files (actually convert to PDF). Closing as WORKSFORME. If you think this is a real problem, provide a command line, and if possible, example output showing what works and what is broken with 9.51
Created attachment 18990 [details] Screenshot from gs 9.50
Created attachment 18991 [details] Screenshot from 9.51
An example code: %!PS 300 300 translate 0 0 100 0 360 arc gsave 1 0 0 setrgbcolor fill grestore stroke 50 0 translate 0 0 100 0 360 arc gsave 0.5 .setopacityalpha 0 1 0 setrgbcolor fill grestore stroke running with gs 9.50 gs -dNOSAFER -dBATCH -sDEVICE=pdfwrite -sstdout=%stderr -sOutputFile=zzz.pdf zzz.ps has the attached output with the expected transparency. Running gs 9.51 with the same commandline or with -dALLOWPSTRANSPARENCY has always _no_ transparency.
There clearly is a problem with pdfwrite, which we we will look into. But as an aside, your example is almost hopelessly incomplete - something I am fairly sure has been pointed out before. If you take a look at our example: http://git.ghostscript.com/?p=ghostpdl.git;a=blob;f=examples/transparency_example.ps you can see there is a *lot* more setup required for transparency to work reliably. Even once we fix the current issue, you really must change your Postscript to drive the transparency operators the way they are intended.
This is exctly the smae problem as Peter's report in 702219, and does rather point up the importance of providing a command line when reporting bugs. The problem only affects pdfwrite and without a command line we are left guessing and can easily try devices that don't exhibit a problem. I'm halfway through a write up on #702219 and I'd prefer to keep tracking this on that thread. *** This bug has been marked as a duplicate of bug 702219 ***