# When converting PDF to EPS, how to prevent pdftops from rasterizing fonts and transparent regions?

Compiling the following code

% Circle.tex
\documentclass[cmyk]{minimal}
\usepackage{pstricks}
\pagestyle{empty}

\topmargin=-72.27pt
\oddsidemargin=-72.27pt
\topskip=0pt
\parindent=0pt

\def\Constant{1}
\paperwidth=2\dimexpr\Constant cm\relax
\paperheight=2\dimexpr\Constant cm\relax

\special{papersize=\the\paperwidth,\the\paperheight}

\begin{document}
\pspicture(-\Constant,-\Constant)(\Constant,\Constant)
\rput(0,0){$E\not=mc^2$}
\pscircle*[linecolor=blue,opacity=0.5](0,0){1}
\endpspicture
\end{document}


with

rem batch.bat takes a file name without extension.
latex %1
dvips -D10000 -t unknown %1
gswin32c -dCompatibilityLevel=1.5 -r10000 -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=%1.pdf %1.ps
pdftops -eps %1.pdf


will yield a diagram as follows.

When I import the diagram from within the following main TeX input file,

% Main.tex
\documentclass[cmyk]{minimal}
\usepackage{graphicx}

\begin{document}
\includegraphics{Circle.eps}
\end{document}


and compiling it with the same batch file, I got a result as follows.

## Question

Using one of the following batches to compile Circle.tex

rem MethodA.bat takes a file name without extension.
latex %1
dvips -D10000 -E %1 -o %1-temp.eps
epstool --copy --bbox %1-temp.eps %1.eps
gswin32c -dCompatibilityLevel=1.5 -dEPSCrop -r10000 -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=%1.pdf %1.eps

rem MethodB.bat takes a file name without extension.
latex %1
dvips -D10000 %1 -o %1-temp.ps
ps2eps %1-temp.ps
epstool --copy --bbox %1-temp.eps %1.eps
gswin32c -dCompatibilityLevel=1.5 -r10000 -dEPSCrop -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=%1.pdf %1.eps


and compiling Main.tex with batch.bat can fix the issue. Because the conversion is done in reversed order, i.e., EPS first then converted to PDF.

Thus the source of problem is pdftops as it rasterizes the EPS whenever the PDF contains transparent regions. So, the question is:

Is there an option or switch to avoid getting jagged outlines when using pdftops?

## Note:

I insist on using batch.bat because it is usually very efficient in consuming time and media storage. Jagged EPS produced by batch.bat apparently becomes larger than ones produced by both MethodA.bat and MethodB.bat. A sad day!

-
 have you tried -level3 ? – Taco Hoekwater Jul 27 '11 at 9:50 @Taco: I have tried all levels, all outputs have jagged outlines. – xport Jul 27 '11 at 9:59 too bad, I was hoping that would have helped, as level3 postscript actually has transparency. Earlier postscript levels did not, so the only option any converter would have is to resort to rasterization – Taco Hoekwater Jul 27 '11 at 10:01 I don't understand. If I do the usual steps "latex"+"dvips -E" and then include the eps I don't find any jaggies. Of course there's the problem of the bounding box, but I thought you had already solved it. – egreg Jul 27 '11 at 10:34 @taco: all postscript levels only support masking rather than arbitrary partial transparency. level3 adds a new way to specify raster masks, that is all. – Lev Bishop Jul 28 '11 at 3:34
show 1 more comment

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).
 In response to "although if this is your goal, why not simply use pdf images with pdftex in the first place?", I cannot use pdflatex because my main TeX input file contains not only external images both also inline PSTricks codes. These inline PSTricks codes cannot be made as external images because they contains \label{} macros. If I insist on making the inline PSTricks codes as external images then all cross-reference will be broken. The inline PSTricks codes are mandatory because they are used to attach annotation to equations for instance. – xport Jul 28 '11 at 7:19 Inserting -Ppdf to dvips -D10000 -E %1 -o %1-temp.eps in MethodA.bat and MethodB.bat does not make any difference that I can recognize. The file size does not change. – xport Jul 28 '11 at 7:21 -Ppdf is not expected to change the size, simply improve the quality of the PDF that is produced from the EPS (it sets -D8000 and renders tex \rules in a way that works better for PDF and maybe other things). – Lev Bishop Jul 28 '11 at 12:58 If your overall goal is to use the figures inline with latex why do you care the file size of the eps figures? The only thing that should then matter is the file size of the PDF that gets produced from them? In that case I would use one of your MethodA.bat or MethodB.bat. Even though that will sometimes make larger eps than using pdftops, the final PDF size will be unaffected, and you can keep using transparency. – Lev Bishop Jul 28 '11 at 13:02