Graphics, Figures & Tables ⇒ Matlab/Latex combo cuts EPS figures on side....

[dhaberberger]

Hi guys,

I'm a new user to Latex but can get around enough to use the template .tex files to produce scientific papers for publication. I'm having a problem with my figures. Let me start by showing you what I usually do:

1. Make a plot in Matlab
2. Save the plot as .eps file
2a. Use GhostScript Viewer to check if the .eps file is ok
3. Use \includegraphics in Latex to include the file

Usually, this works great, that is if my matlab plot isn't too wide! If the figure window for matlab is too wide, when I create the .eps file part of the figure is off the left and right sides of the page in GhostScript Viewer. Now, I've since learned about bounding boxes and in the viewer, if I click the option "EPS Clip", not only do I see the entire plot (all info there, nothing clipped), but the bounding box is perfect. So, in the viewer, everything is fine. However, when I try to input this into Latex, it cuts the left side of the figure. For some reason it's fine with the right side of the figure. What I am thinking is that Latex doesn't like negative values for the bounding box, because the left side goes into negative values for the x-pos. I've tried so many things (at least that I could find myself online). The majority of them involved different ways to make an .eps file from Matlab, but they almost all result in the same problem (some have other problems!). So I'm really hoping I can solve this issue on the Latex side. Does anyone have ideas?

Thanks so much for your help.
Dan

[localghost]

Why don't you just show the problem by means of a full and minimal example? Emphasize is on „minimal“. Attach one of the problematic EPS files for examination by uploading it to the forum server.


Best regards and welcome to the board
Thorsten

[dhaberberger]

I have now read the instructions on creating a minimum example and this was the best I could do:

\documentclass{minimal}
\usepackage{graphicx}

\begin{document}
\includegraphics[height=1in]{test}
\end{document}

In order to use documentclass{minimal}, I needed to add the 'graphicx' package to use the \includegraphics command. I don't know how else to show the problem, I hope this is satisfactory. I did find an additional fact, though: after the code is run, if I check the .dvi file, the complete figure is shown! Only after I run dvi2pdf and view the pdf does the problem appear where the left side of the figure is cut off (which corresponds exactly to where the bounding box goes negative--see first posting for problems statement). I have attached the test.eps file. I hope I have defined the problem better.

Thanks,
Dan

[localghost]

[...] I don't know how else to show the problem, I hope this is satisfactory. I did find an additional fact, though: after the code is run, if I check the .dvi file, the complete figure is shown! Only after I run dvi2pdf and view the pdf does the problem appear where the left side of the figure is cut off (which corresponds exactly to where the bounding box goes negative--see first posting for problems statement). [...]

At first let me tell you that the file you provided is displayed correctly in Okular as well as GwenView on my Linux system². So there is no problem with the file itself. And your MWE is a very good one. Your descriptions of the compilation route have been very helpful and important.

I can comprehend the problem when using the compilation route »LaTeX → DVI → PDF« just as you described. This route is known to cause problems when it comes to including EPS files. It works fine for me when compiling via PS using the »LaTeX → DVI → PS → PDF« route. I suggest that you test this preferable procedure and use it in the future. That won't do any harm and it costs only a minimum of additional compilation time, which is negligible. This requires Ghostscript installed. I attach the file I produced with compilation via PS.

What could be interesting for you in this context is the fact that you can convert your EPS files to PDF with the command line tool epstopdf or »on the fly« with the epstopdf package. This would allow you to compile with PDFLaTeX directly.

[dhaberberger]

Thank you very much localghost....that worked great!
From now on I'll just use the route you suggested : LaTeX-dvi-ps-pdf
This makes things so much easier using .eps files from Matlab (90% of my figures)
Thanks again,
Dan

To repeat the problem and solution above: When saving wide figures in Matlab to .eps files, the bounding box coordinates has negative values on the left side. Then compiling in the following order:

LaTeX - dvi - pdf

causes the left side of the figure to be cut off. A solution was found in changing the compiling to:

LaTeX - dvi - ps - pdf

This produces a document with the full figures.

[literatematlaber]

Not completely.
How about importing EPS-files with undefined bounding box?
I want to share my experience.
A year ago I wrote an m-file that I used to generate some figures.
I saved them as EPS-files for inclusion in a LaTeX document but I didn't specify 'paper position' option ('paper size' was [10 12] cm). Nevertheless, \includegraphics command worked perfectly and could scale/resize file according to 'width', 'heigth' parameters. That was done by LaTeX->dvips->ps2pdf driver on 32 bit Windows XP with MikTex 2.7 and MATLAB R2008A.
Time went by and I needed that document again. I recompiled it with existing EPS-files, but received "overful" boxes and huge clipped figures that didn't fit the page. \includegraphics arguments 'scale', 'width', 'heigth' etc. didn't work.
That was done on 64 bit Kubuntu 9.10 with Texlive 2009.
I also tried to compile it on Windows XP with the same Texlive 2009 but it didn't work.
So the question is: why? EPS-files are the same! So it should work!
Obviously, the problem is in EPS-file, LaTeX cannot read 'BoundingBox' argument from that file but I don't think that problem is in MATLAB (that is also possible, MATLAB is not bug-free), but in LaTeX distribution. That sounds stupid since LaTeX is platform independent, but what I can't see any other reasons. I spent more than one day debugging it, eventually after adding code shown below and regenerating EPS-figures on MATLAB R2010A, it worked. Anyways, with 99% confidence I can say that you will not encounter any problems during graphics inclusion process in LaTeX if you export MATLAB figures programmatically as shown below (don't use GUI's 'Save as' option in the figure's menubar):

Solution (sample application):

• figure('NumberTitle', 'Off', 'Name','Random Numbers');
  % Set paper size for the output *.eps file
  set(gcf, 'PaperUnits', 'centimeters');
  width=9; %cm
  heigth=6; %cm
  set(gcf, 'PaperSize', [width heigth]);
  % Adjust position of the figure on the screen (for correct representation of fonts)
  set(gcf, 'Units', 'centimeters');
  set(gcf, 'Position', [0 0 width heigth]);
  % Adjust position of the figure on the paper
  set(gcf, 'PaperPosition', [0 0 width heigth]);
  plot(rand(1,100));
  xlabel('Experiment');
  ylabel('Outcome');
  title('Title')
  print('-depsc2', '-loose', 'RandomNumbers.eps');

The idea is to put the figure of size [width height] on a paper of the same size, so x and y coordinates are zero. I advise you to use 'epsc2' driver (-depsc2), the file occupies small space and picture is colorful.
Then import EPS-file with the help of \includegraphics{RandomNumbers.eps} in LaTeX. That's it. Read MATLAB's documentation for details.