# EPS Figure is cutoff on right when built to pdf, .eps is fine

I have to make an .eps file from a large png for publication in PRL. When viewing the .eps in ghostscript/inkscape/illustrator/... it looks fine, but when I build it into a pdf using latex -> DVI -> PDF in TexnicCenter/TexMaker its got a big white block covering the right side.

I generated the latex using LyX export, and have been trying to get it to compile as well as it did in LyX. The figures look perfect when compiled with pdflatex in LyX, so there must be something different with my build profile that's obscuring my figures? Any tips?

EDIT: The minimal example below produces a 'file not found' for the graphic file using pdfLaTeX, and compiles with the figure cutoff on the right when compiled with latex -> DVI -> PDF. Some of my other .eps figures display perfectly when placed in that float, while others don't show at all. However, the .eps all look fine when viewed on their own, and appear to have good bounding boxes in ghostview.

\documentclass{paper}
\usepackage[T1]{fontenc}
\usepackage[latin9]{inputenc}
\usepackage{float}
\usepackage{amsmath}
\usepackage{graphicx}
\makeatletter
\makeatother
\usepackage{babel}
\begin{document}
\title{Blah}
\author{Bleh}
\begin{abstract}
Abstract goes here.
\end{abstract}
\maketitle
\begin{figure*}[t!]
\begin{centering}
\includegraphics[width=0.75\textwidth]{phasediagramstogether2}
\end{centering}
\caption{This figure is cutoff on the right, with a big white box}%
\label{RDFsandSamples}
\end{figure*}
\end{document}


The error log generated using pdfLaTeX: http://pastebin.com/MRGtUsQJ

The error log for latex -> DVI -> PDF: http://pastebin.com/QA4tVuzY

• What if you compile with pdfLaTeX in Texmaker as well, rather than going via DVI? – Torbjørn T. Sep 27 '13 at 21:26
• Using pdfLaTeX (latex -> PDF), it gives a series of 'file not found' errors for each of my graphics and .bib's. I must be doing something wrong with pdflatex? With latex -> PS -> PDF, its a jumbled mess with no figures. – Ron P Sep 28 '13 at 3:23
• I don't know what is going on. Can you reduce your LaTeX code to the minimal showing the problem, and edit your post to include that? – Torbjørn T. Sep 28 '13 at 8:04
• I've added a minimal example showing it, though it also seems to work fine with some .eps graphics and get worse with others. The error log I pastebinned might be more informative. I probably shouldn't post the figures publicly since they're for publication, but if an individual thinks they can help privately that would be great. – Ron P Sep 28 '13 at 18:40
• To avoid the babel error I think adding english as a package option, i.e. \usepackage[english]{babel}, would do the trick. Then try adding \usepackage{epstopdf}. pdflatex cannot use EPS files directly, so it has to be converted to PDF. In newer versions of TeX Live at least this happens automatically, but that is perhaps not the case for MikTeX 2.8. epstopdf does the conversion, but you need to enable shell-escape I think: tex.stackexchange.com/questions/82699/… (you may need --enable-write18 instead of --shell-escape) – Torbjørn T. Sep 28 '13 at 20:14

pdflatex cannot handle EPS files directly, and you'll note from the log file that .eps is not among the filetypes it considers:

l.38 ...hics[width=0.75\textwidth]{paperfractalds}

I could not locate the file with any of these extensions:
.png,.pdf,.jpg,.mps,.jpeg,.jbig2,.jb2,.PNG,.PDF,.JPG,.JPEG,.JBIG2,.JB2


Therefore, the file has to be converted to a different format, normally PDF. The package epstopdf does this for you, so adding

\usepackage{epstopdf}


to the preamble and compiling with shell-escape enabled (see e.g. How to enable shell-escape in TeXworks?) should take care of that. You may need to use the flag --enable-write18 instead of --shell-escape (they do the same thing, but the former is used by MikTeX).

Note that with newer versions of TeX Live at least, this conversion is handled automatically, so there is no need to add that package or enable shell-escape. I do not know if the same is the case for MikTeX 2.9.

I think LyX perhaps handles these conversions itself, hence not needing that package, but I may be completely wrong. Asking a question at the lyx-users mailing list is probably the best way to figure that out. Also, I though EPS files would work fine when compiling via DVI, so why that doesn't work I don't know.

The log also shows an error from babel, which can occur for example if you compile once, then remove a language option from \documentclass or babel and compile again (see https://tex.stackexchange.com/a/82673/586). \usepackage[english]{babel} should fix that part I guess.

• The message Overfull \hbox (138.40732pt too wide) in paragraph at lines 33--33 (for file: paperfractalds.eps Graphic file (type eps) <paperfractalds.eps> ... would seem to show the figure is bigger than the paper is able to hold -- getting for 2in too wide. could this explain your problem? – wasteofspace Sep 29 '13 at 10:06
• You are right that LyX often tries to take care of the conversion (through external conversion tools). The command used for converting can be controlled with converters. (Tools > Preferences > File Handling > Converters) – scottkosty Sep 26 '14 at 17:49

This is likely an issue with the bounding box of the EPS figure when it is being processed by dvi2pdf. Torbjørn's suggestion is good, but if you'd rather stick with EPS files, try Latex->dvi2ps->ps2pdf, this tends to work better.

• This is rather a comment than an answer! – user31729 Sep 26 '14 at 13:21
• Unfortunately I would need 50 reputation to comment (on an answer that isn't my own :/). – FrankD Oct 3 '14 at 15:50

I had the same issue. The deviation via LaTeX->dvi2ps->ps2pdf did the job beautifully.

Thanks Tom