I have a TeX file, which is typeset by XeLaTeX.

The file has \includegraphics{coverimage.eps} on the first page, and coverimage.eps is located in the same directory as the TeX file. OS: MacOS 10.6.5, TextMate 1.5.10, xelatex 3.1415926-2.2-0.9997.4 (TeX Live 2010)

If I run xelatex doc.tex in console, file compiles without errors, and eps file is included. If I typeset it in TextMate (xelatex engine is selected in preferences), I get the following error:

** WARNING ** pdf_open: Not a PDF 1.[1-5] file.
** WARNING ** Failed to include image file "./coverimage.eps"
** WARNING ** >> Please check if
** WARNING ** >> rungs -q -dNOPAUSE -dBATCH -sPAPERSIZE=a0 -sDEVICE=pdfwrite -dCompatibilityLevel=%v -dAutoFilterGrayImages=false -dGrayImageFilter=/FlateEncode -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -sOutputFile=%o %i -c quit
** WARNING ** >> %o = output filename, %i = input filename, %b = input filename without suffix
** WARNING ** >> can really convert "./coverimage.eps" to PDF format image.
** WARNING ** pdf: image inclusion failed for "coverimage.eps".
** WARNING ** Failed to read image file: coverimage.eps
** WARNING ** Interpreting special command PSfile (ps:) failed.
** WARNING ** >> at page="1" position="(107.149, 124.566)" (in PDF)
** WARNING ** >> xxx "PSfile="coverimage.eps" llx=0 lly=0 urx=408 ury=526 rwi=3809 

and there is no image included in the resulting file (but text looks ok).

I am not sure whether it is the error of xelatex or TextMate LaTeX bundle. What I tried to do:

  1. As I said, xelatex doc.tex from console works. The exact command line that TextMate uses is:

    xelatex -interaction=nonstopmode -file-line-error-style -synctex=1

    But it works from console too.

  2. If I convert the image to pdf (and fix the .tex file accordingly), typesetting from TextMate works too.

  3. I tried running rungs with parameters specified in the error message, and got valid .pdf file with image as a result.

  4. I compared .log files from typesetting in TextMate and in console, they are absolutely identical except for this error message (in particular, version of xelatex is the same).

Does anyone know what can cause this? Please tell me if you need any additional information.

Thank you in advance.

  • I can replicate the problem. The problem doesn't exist with TeXShop, however. So it seems that it is something with TextMate itself.
    – Alan Munn
    Commented Jan 3, 2011 at 3:19
  • That's why I initially posted this question to superuser.com. No idea why it got migrated here.
    – fjarri
    Commented Jan 3, 2011 at 5:45

2 Answers 2


As rungs is also provided by Ghostscript, my guess is that you have an older installation of Ghostscript on your machine. Somehow, the PATH in TextMate is different than the path in your Terminal, and so the older version is getting called only within TextMate.

To test this, you can use TextMate's "Execute Line Inserting Result" (bound to ^R). In a new TextMate document, try the following commands:

which rungs

rungs -v

echo $PATH (note that TextMate adds its own resources to $PATH, so this will be different. Focus on the order of the system directories like /usr/texbin and /usr/local/bin.)

and check the result against your terminal. If this is indeed the problem, then you can solve this issue by manually setting the PATH variable in TextMate's advanced preferences window to be the same as in your Terminal.

TextMate's Advanced Preferences

Edit: Does this minimal example compile for you, with either XeLaTeX or pdfLaTeX? I used demo.eps from /usr/local/texlive/2010/texmf-dist/doc/latex/guide-to-latex/demo.eps.

  • I thought that this might be the problem, but on my system I have only one rungs, and the paths are the same: /Applications/TextMate.app/Contents/SharedSupport/Support/bin/CocoaDialog.app/Contents/MacOS:/usr/texbin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/TextMate.app/Contents/SharedSupport/Support/bin from within TextMate and /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin:/Users/alan/bin in the shell. But 'which rungs` returns /usr/texbin/rungs in both. And I can replicate the problem.
    – Alan Munn
    Commented Jan 3, 2011 at 17:23
  • @Alan: Interesting. I cannot replicate the problem. OS 10.6.5, TextMate 1.5.10, XeTeX 3.1415926-2.2-0.9997.4 (TeX Live 2010).
    – mbauman
    Commented Jan 3, 2011 at 17:32
  • I have exactly the same setup. Very weird.
    – Alan Munn
    Commented Jan 3, 2011 at 18:16
  • @Alan, yes, and it's the same as the OP, too. I wondered if something funky might be going on in the tmbundle, so I tried both the default version as well as the latest version on GitHub, but both worked fine for me. I'm stumped.
    – mbauman
    Commented Jan 3, 2011 at 21:02
  • which rungs gives me /usr/texbin/rungs both in Terminal and TextMate, and echo $PATH results resemble Alan's too. Your minimal example typesets with the same error in TextMate (sorry, I should have provided such example myself). pdflatex (in TextMate) gives the following error !!! Error: Cannot open Ghostscript for piped input. Both xelatex and pdflatex successfully typeset this example from Terminal.
    – fjarri
    Commented Jan 4, 2011 at 5:34

I finally found the solution. I tried searching for Cannot open Ghostscript for piped input phrase I mentioned in the comment and found this message. Added /usr/local/bin to PATH variable in TextMate and it fixed the problem.

  • Yes, this fixed the problem for me too. I should have noticed the difference between the two paths.
    – Alan Munn
    Commented Jan 5, 2011 at 6:49
  • Interesting. which gs is indeed located in /usr/local/bin. Interesting that TexLive would place some Ghostscript commands in /usr/texbin (like rungs) and others in /usr/local/bin (gs as well as all the ps2pdf, ...2..., etc., utilities)
    – mbauman
    Commented Jan 5, 2011 at 21:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .