TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

\includegraphics cannot handle filenames that contain more than the one dot, separating the filename from the extension. Apparently it uses everything after the first dot as extension and then, of course, complains about an unknown graphics extension.

This is annoying as I very often have filenames that contain parameter values, e.g. plot_a0.4_b0.6.pdf.

Is there a way to teach LaTeX to interpret only the string behind the last dot as extension?

share|improve this question
up vote 123 down vote accepted

You can hide the other dots by masking them from TeX's token scanner with { }, i.e.:


works fine.

Note that the extension can also be dropped, then a list of default extensions is used. See the graphicx manual for more information. If you want to do this, you need to double group the filename, which makes three together with the one for the arguments:

share|improve this answer
Nice and simple solution, thanks! – fuenfundachtzig Feb 18 '11 at 18:50
@uenfundachtzig: I find grffile easier as it provides other features too (like spaces in filenames). – Martin Schröder Dec 31 '11 at 11:46
@MartinSchröder Definitely easier .. when it is supported by your other packages. – kando Jun 10 at 15:52
Does this work with any other characters which are typically bounced back? (Spaces, etcetera?) – kando Jun 10 at 15:59
@kando: The dots are special here because the macros looks for a file extension. But it should work with spaces as well, as they are also handles special by the underlying TeX macros. Other, normally problematic characters like underscores should work fine out of the box. – Martin Scharrer Jun 14 at 19:31

You can use package grffile with option multidot.


share|improve this answer
Specifying options doesn't seem to be necessary; \usepackage{grffile} was sufficient when I tried it. – Mechanical snail Apr 26 '13 at 20:22
Even works for \includepdf from the pdfpages Package. Excellent! – jakob r Mar 14 '15 at 23:24
grffile is the best. I had to drop it due to compatibility issues with another package I could not part with a couple years ago. It was so sad. I think the perpetrator was KOMA. For me, despite the warnings, KOMA works in harmony with geometry .. why not grffile too. : / – kando Jun 10 at 15:38

Actually supporting such file names was part of the initial design spec for graphicx. The filetype is defaulted from the extension but for cases like this there is a type key so you can go type=eps or type=bmp or whatever is needed.

(copying an answer from a question marked as duplicate of this one)

For example, to tell latex it is eps type and the extension to use for the file itself and to find the bounding box, you can use:






this includes example.1.eps using xelatex, or latex/dvips etc.

share|improve this answer
That doesn't work for me (at least for type=pdf and type=png): either LaTeX complains wrongly that it cannot find image size, or (after giving size as parameters) fails with division by zero error. – Jakub Narębski Aug 2 '12 at 15:53
latex can't read the image size so you need to give it in the arguments or in a matching .bb file with a postscript style bounding box comment. I would guess you used the arguments and went height=1cm that gives div by zero as that is a scale option to resize the figure so it divides the requested height by the natural size (which is still set to 0). You need to use the bb key or natheight=1cm, natwidth=1cm to set the natural height. – David Carlisle Aug 2 '12 at 15:57
I have used bb (and ext=.pdf) and it didn't work -- still "ERROR: LaTeX Error: Cannot determine size of graphic in CUDA_4.0_Math_Libraries_Performance_6_14.p4-crop.pdf (no size specifed).". I didn't know about the difference between height and natheight and that I should have used the latter. – Jakub Narębski Aug 2 '12 at 16:07
FYI: The command was: \includegraphics[type=pdf,ext=.pdf,bb=0 0 595 842]{CUDA_4.0_Math_Libraries_Performance_6_14.p4-crop} and the file was CUDA_4.0_Math_Libraries_Performance_6_14.p4-crop.pdf (the bounding box was taken from converted to PostScript). – Jakub Narębski Aug 2 '12 at 16:10
hmm cuda math libraries, too close to the day job:-) I think those arguments should work (if it doesn't, it's possible my former self did something wrong I may test later...) – David Carlisle Aug 2 '12 at 16:33

While the question is answered for the generic case - I often have a case, where I have files with constant (unchanging), yet unstandard extensions; and where I'd like to use these files as input "as is" to pdflatex in a batch script context (meaning, I wouldn't want to code any parsing logic in respect to filenames, either in the Latex code, or the batch code).

For instance, the usual \includegraphics{mydir/file01.csv_.pdf} would fail with:

! LaTeX Error: Unknown graphics extension: .csv_.pdf.

One thing that works, is as per the answer by @DavidCarlisle:


... but this requires me to strip the extension from the filename, so I'd have to introduce filename parsing logic somewhere.

However, what really works for me is using \DeclareGraphicsRule{ext}{type}{read-file}{command} (see grfguide.pdf: Packages in the 'graphics' bundle):

% preamble:

% ...


% ...


... and this seems to work fine, without any changes to the filename argument of \includegraphics. Note that command argument can be left empty (it's for a system conversion otherwise), and read-file is where do we read the size/bounding box information from: since the .csv_.pdf is a .pdf file proper, with * we simply say - read the size from the same file that has matched the declared extension.

share|improve this answer

It is possible to automate Martin Scharrer's routine:

      \@latex@error{Filename is empty;
        \ifcsnullTF\flext{}{ extension '\flext'}}\@ehc


% The next one gives error because there is no filename:
%  \parsegraphicsfilename{.pdf}

Real-life application:


Sample output

share|improve this answer
So many lines for something \usepackage[multidot]{grffile} does automatically... – Martin Schröder Dec 31 '11 at 11:45
Just an exercise for a bored student on Christmas break. – Ahmed Musa Dec 31 '11 at 11:53

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.