# Why does my EPS header have % Produced by xpdf/pdftops 3.02pl4?

I have a simple input file contains PSTricks code as follows.

% sample.tex
\documentclass[cmyk]{minimal}
\usepackage{pstricks}
\usepackage[paperwidth=144bp,paperheight=108bp,margin=0bp]{geometry}

\parindent=0bp
\begin{document}
\begin{pspicture}(\paperwidth,\paperheight)
\psframe[linecolor=red](\paperwidth,\paperheight)
\end{pspicture}
\end{document}


It is compiled using:

latex -interaction=nonstopmode %1
dvips -R -t unknown %1
ps2pdf -dAutoRotatePages#/None -dCompatibilityLevel#1.5 -dPDFSETTINGS#/prepress %1.ps
pdftops -level3 -eps %1.pdf %1-temp.eps
epstool --copy --bbox %1-temp.eps %1.eps


Before invoking the epstool, my sample-temp.eps contains the following:

%!PS-Adobe-3.0 EPSF-3.0
% Produced by xpdf/pdftops 3.02pl4
%%Title: sample.dvi
%%LanguageLevel: 2
%%DocumentSuppliedResources: (atend)
%%BoundingBox: 0 0 144 108
%%BeginProlog
%%BeginResource: procset xpdf 3.02pl4 0


Note: I don't understand why the second row does not exist in Herbert's EPS.

I failed to execute epstool because the second row has a single % that should be %%. The following screenshot shows the error log.

Based on Lev's comment, I tried to add -level3 switch to pdftops, but it still does not solve the problem. I don't understand what sed in Lev's comment, what is that?

This is my pdftops version:

-
I gave the solution to this problem in a comment on this answer – Lev Bishop Jul 12 '11 at 1:46
using -leve3 is nonsense, nearly all printers do not have this level installed – Herbert Jul 12 '11 at 6:12
I see, that is the one which uses the xpdf lib, don't know if there is a version with poppler for Windows. – Herbert Jul 12 '11 at 6:24
@xport: On Linux the command isn't part of TeXLive because it is already there. – Herbert Jul 12 '11 at 6:55
@Herbert. Indeed most printers do not use level3. However most people are using pdftoeps to produce postscript for later conversion to a different format, most often because they are integrating with a postscript-based journal publisher workflow, that will later be distilled to PDF for distribution. Anyway, my comment here was in relation to using sed to fix the missing %. – Lev Bishop Jul 12 '11 at 13:50

my eps:

 %%BoundingBox: 0 0 145 109
%%HiResBoundingBox: 0.000 0.000 144.000 108.000


with the above sequence under Linux

voss@shania:~/Documents> epstool --bbox --copy latex6-temp.eps latex6.eps
"gs"  -dNOPAUSE -dBATCH -sDEVICE=bbox   -c "<</PageSize [9400 9400] /PageOffset [3000 3000]>> setpagedevice" -f "/tmp/gsviewuW8XZu"
GPL Ghostscript  9.00 (2010-09-14)
This software comes with NO WARRANTY: see the file PUBLIC for details.
%%BoundingBox: 3000 3000 3145 3109
%%HiResBoundingBox: 3000.000073 3000.000073 3144.000490 3108.000491

voss@shania:~> epstool --help
epstool 3.08 2005-06-06
Copyright 1995-2005 Ghostgum Software Pty Ltd
Usage: epstool command [options] inputfile outputfile


The header of <file>-temp.eps with a modified bbox (doen by hand)

%!PS-Adobe-3.0 EPSF-3.0
%%LanguageLevel: 2
%%DocumentSuppliedResources: (atend)
%%BoundingBox: 72 72 72 72
%%DocumentSuppliedResources: (atend)
%%BeginProlog
%%BeginResource: procset xpdf 3.00 0


and the pdftops version:

voss@shania:~> pdftops --help
pdftops version 0.12.4
Copyright 2005-2009 The Poppler Developers - http://poppler.freedesktop.org
Copyright 1996-2004 Glyph & Cog, LLC
Usage: pdftops [options] <PDF-file> [<PS-file>]

-
I can confirm it. epstool 3.08 2005-06-06. BTW I think it is pretty stupid that BBox is enlarged by epstool for no good reason. – przemoc Jul 11 '11 at 17:43
@xport: epstool recalculates the bounding box, this is why the program is used ... – Herbert Jul 11 '11 at 17:55
@xport's comment was meant as a joke, but there was no reduction (possibly another typo or I read it wrongly) -- BBox was enlarged and HiResBBox is the same as original BBox, which is strange at least (BBox > HiResBBox part, because it could be easily set to exact size). – przemoc Jul 11 '11 at 17:59
@xport: sample-temp.eps has %%BoundingBox: 0 0 144 108. I believe Herbert has the same line. – przemoc Jul 11 '11 at 18:04
@xport: It's not only Herbert's EPS. I confirmed it I have the same lines there, thus it's only you who have different values. :) My hunch is that it works the other way, i.e. first HiResBBox is calced and then BBox, where maybe some really strange rounding is used. – przemoc Jul 11 '11 at 18:08