Searching for a better workflow to get a cropped PDF and EPS graphics - Stage 1

Question

I am using TeX Live 2010. I don't use MikTeX anymore because of many troubles I found in the past.

Input files:

gridon.tex:

% gridon.tex
\documentclass{minimal}
\usepackage{pstricks}

\pagestyle{empty}
\begin{document}

\begin{pspicture}[showgrid=true](3,3)
\pscircle(1.5,1.5){1}
\rput[tr](3,3){3}
\end{pspicture}

\end{document}

gridoff.tex:

% gridoff.tex
\documentclass{minimal}
\usepackage{pstricks}

\pagestyle{empty}
\begin{document}

\begin{pspicture}[showgrid=false](3,3)
\pscircle(1.5,1.5){1}
\rput[tr](3,3){3}
\end{pspicture}

\end{document}

main.tex:

% main.tex
\documentclass{minimal}
\usepackage[hiresbb]{graphicx}
\begin{document}

\includegraphics[scale=2]{gridon}
\vspace{5mm}

\includegraphics[scale=2]{gridoff}
\end{document}

Methods:

MethodA.bat:

echo off
latex %1
dvips %1
ps2pdf %1.ps
pdfcrop --hires %1
pdftops -eps %1-crop.pdf

MethodB.bat:

echo off
latex %1
dvips %1 -E -o %1.eps
epstool --copy --bbox %1.eps %1-crop.eps
epstopdf --hires %1-crop.eps

Results:

Answer 1

I would recommend method A, because the EPS files will in general be much smaller.

You noticed "bad" cropping with method A. The reason for this is subtle: your use of pstricks produces a PDF where the font used for labelling the grid (eg, the figure "3") is Helvetica and it is not embedded in the PDF. Therefore ghostscript and adobe reader have to use a subsitute font. Most viewers (including the many viewers based on ghostscript, also xpdf) will use a version of Helvetica. Adobe's viewer will substitute ArialMT (on windows at least), which is a slightly different shape and therefore gets cut off. You can check this with Adobe reader on the "fonts" tab of the "document properties" dialog. You can solve this problem by producing a file with the fonts embedded. One way to do this is to change your method A to use ps2pdf -dPDFSETTINGS#/prepress %1.ps %1.pdf.

Why does method B seem to be superior? Actually I was quite confused for a while because on Ubuntu the two methods do produce the same bounding box. Which is to be expected, since pdfcrop and epstool both use gs -sDEVICE=bbox to generate it. So why do you see a difference? Well, I found that the miktex version of epstopdf has a bug in it: it rounds the bounding box to an integer number of points. In this particular case this had the effect of cancelling the clipping, but in general it could make the clipping worse. I'll file a bug against miktex tomorrow, but in the meantime this is another reason to prefer method A if you are using miktex. (The miktex version of epstopdf is a reimplementation in C of the bugless original perl script).