It can't be done. The PostScript language does not support arbitrary opacity (only fully opaque and completely transparent). See this wikipedia reference.
The Ghostscript language, however, does support arbitrary opacity, as an extension to the language (extra commands such as .setopacityalpha
). See here for details. This is how pstricks made an apparently-transparent eps file.
In all your dozens of questions about figure conversion, I don't recall that you have ever explained why you want to produce eps versions of your figures (which makes it much harder to answer all those questions, by the way). If your reason is only to use the figures in a latex->dvips->ps2pdf workflow, where you can guarantee that the conversion to pdf will use ghostscript, then the .setopacityalpha
method is appropriate (although if this is your goal, why not simply use pdf images with pdftex in the first place? or at least add -Ppdf
to your dvips invocation to make pdf-optimized eps?). However, the reason people usually want eps figures is because they are giving the figures to some publisher who does not accept pdf, in which case the publisher will almost certainly also not accept ghostscript-specific extensions and the .setopacityalpha
method will fail also. If you happen to know that the publisher uses Adobe Distiller, then there is another way to produce transparent-extended EPS, via the pdfmark
extension, described here. You can ask pstricks to use the pdfmark
method for opacity by replacing pstricks.con
by distiller.cfg
(distributed with pstricks). (You will have to ask your publisher to set /AllowTransparency true
in their joboptions file).
If you need a strictly standards-conforming EPS file that will work with all PostScript engines, then you need either to avoid transparency altogether or use something like the ps2pdf followed by pdftoeps method as given in your batch file, which will rasterize the transparent parts of the image. (I think the next version of of pdftops will at least allow you to specify a rasterization resolution). Due to the rasterization, the EPS will in general be larger, of course.
\documentclass{article}
\usepackage{pst-solides3d}
\begin{document}
\psset{viewpoint=10 60 15 rtp2xyz,Decran=5}
\begin{pspicture}[solidmemory](-5,-5)(6,12)
\psSolid[object=point,args=10 -36 0,name=L]
\psSolid[object=point,args=-36 10 0,name=R]
\psSolid[object=line,linecolor=blue,linestyle=dashed,linewidth=2pt,args=R L]
\psSolid[object=parallelepiped,a=6,b=3,c=3,RotZ=30,name=Cube,action=draw*](0 0 2)
\multido{\iA=0+1}{8}{%
\psSolid[object=point,definition=solidgetsommet,args=Cube \iA,name=C\iA]}
\multido{\iA=0+1}{8}{%
\psSolid[object=line,linecolor=blue!40,linestyle=dotted,args=L C\iA]
\psSolid[object=line,linecolor=blue!40,linestyle=dotted,args=R C\iA]}
\psSolid[object=parallelepiped,a=6,b=3,c=3,RotZ=30,name=Cube,action=draw](0 0 2)
\end{pspicture}
\end{document}
![enter image description here](https://i.stack.imgur.com/HFkH8.png)
Best Answer
With PDF and PostScript (and so, with PSTricks and TikZ/pgf), you can use two rules to determine if a point is inside a path: 'nonzero rule' or 'even odd rule'.
The following code (TikZ) shows the difference:
The PDF file is transparent. To get a correct PNG file (with transparencies), use
convert
from ImageMagick (pdftopnm
seems to add a white background).The following PSTricks code shows the difference (using or not using
eofill
fillstyle -eofill
means even odd filling):With PSTricks,
eofill
can't be used with some other fill styles like hlines (may be a bug). You can always use nonzero rule (the default rule used by PSTricks) and correct direction for your hole: