Created attachment 18164 [details] simple LaTeX transparency test A Debian user reports at https://bugs.debian.org/941074 that pdf2ps fails to handle transparency in SAFER mode. From above bugreport: To reproduce the bug, run ps2pdf14 transparent-things.ps (no transparency in transparent-things.pdf) and ps2pdf14 -dNOSAFER transparent-things.ps (transparency in transparent-things.pdf).
PostScript does not support transparency (with some caveats). Ghostscript has some, entirely non-standard, operators to apply the PDF transparency model in PostScript. These extensions are fragile; using them in the wrong order, or simply in ways that our code doesn't normally use them, can lead to segmentation faults and core dumps. (Note that a quick peruse of the supplied example file suggests it is not using the Ghostscript transparency operators correctly. I'm somewhat surprised this file produces the output it does, since it doe snot push the PDF14 compositor at all. Even if it works now, its likely to fail in the future.) Since they are non-standard, and liable to cause errors, the decision was taken to restrict their usage when running PostScript, as this is (obviously) a security risk. A malicious user might be able to take advantage of a crash. In addition, previously the default was to run Ghostscript withou SAFER but, as we've been warning for years (if not decades) that we intended at some future date to make SAFER the default, we've now decided (in the light of recent security reports) to implement that. The LaTeX PostScript program looks for the presence of the Ghostscript-specific operators it is using, and implements 'bit bucket' versions of them if they are not found. This prevents Ghostscript from throwing an error, which is why the result silently omits the transparency. That's not the fault of Ghostscript, its a deliberate decision on the part of the PostScript programmer. So, if you want to use these non-standard operators, you are going to have to run Ghostscript with -dNOSAFER.