#2581 epstopdf creates .eps.pdf file instead of .pdf as in TeXLive

[U_Fischer]

I'm not sure if the following is really a bug, it could be intentional and even a sensible behaviour to avoid that files are overwritten. In this case it would be good if the help message would mention the behaviour (and I would have to inform the maintainer of the epstopdf-base package).

Calling epstopdf testbild.eps creates a file testbild.eps.pdf:

D:\MiKTeX2.9\miktex\bin\mgs.exe -q -sDEVICE=pdfwrite -dSAFER -dAutoRotatePages=/None -sOutputFile=.\testbild.eps.pdf - -c quit

This behaviour is different to TeXLive where the same call creates testbild.pdf.

This is a problem for the epstopdf package: with miktex setting an empty suffix doesn't work https://tex.stackexchange.com/questions/357060/miktex-eps-to-pdf-converter-problem.

[Christian Schenk]

This is a bug, i.e., the output file should be named testbild.pdf.

Please note that MiKTeX epstopdf is not the Perl script (epstopdf.pl) which is a part of the mentioned epstopdf-base package (texlive). Perhaps I should rename epstopdf.exe to miktex-epstopdf.exe.

[U_Fischer]

I know that the miktex epstopdf.exe is a wrapper around a ghostcript call and not a wrapper around the perl script.

Regarding a renaming:

• There should be an epstopdf.exe reachable as it is the call used by epstopdf-base (which is nowadays loaded by default by graphics.cfg and so is always active). It would confuse users if the background conversion of eps to pdf would suddenly stop to work.
• I'm not sure if the perl-script works flawlessly with miktex (I know that pdfcrop does not, http://tex.stackexchange.com/questions/292558/problem-with-pdfcrop-on-windows-10).
• As miktex doesn't contain it own perl an epstopdf.exe based on the perl script would fail for users without external perl.