Take the 2-minute tour ×
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

\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

5 Answers 5

up vote 67 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

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

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

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

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

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.