Watch what you name graphics files in LaTeX

A while back I was trying to paste a figures into a LaTeX document this evening with names like foo_27.png and foo_32.2.png, putting a parameter value into the name of the plot. The former worked but the latter didn’t.

It turns out the \includegraphics command parses the file extension in a naive way to determine the file type. When it sees foo_27.png, it says “OK, a .png file”. But when it sees foo_32.2.png, it says “.2.png? I’ve never heard of that file type.”

Related post: Including graphics in LaTeX documents

12 thoughts on “Watch what you name graphics files in LaTeX

  1. Is that a bug or a feature? In my experience that is REALLY naive, but maybe there are reasons for it in operating systems other than Windows.

  2. Probably a bug in this case, but IIRC the perl filename parser lets you define the boundary between basename and extension. If so, then presumably there are some occasions where non-standard extensions are used, if only in someone’s perl code.

    My recollection from my days of primarily working in Unix is that the OS doesn’t have much to do with extensions — they were more often created, used, and understood by specific applications. Thus it is much more likely that extensions are longer than 3 characters and may have unusual characters in them. The OS basically only distiguishes between executable and non-executable files (and directories of course). Some applications look at the header of a file for attributes, too.

    This may have changed with the more common use of windows and desktops on *nix machines. Presumably in that case one would want more specific information about file types for use in context-specific behavior, double-clicking, and right-clicking.

    Anyway, since LaTeX grew up in Unix environments, the parser may not be ‘naive’ so much as conforming with the possible vagaries of Unix filename extensions.

    That’s why I’d say it is a bug in this case — since John is using LaTeX on a Windows machine, the parser should default to Windows standards. Perl does this by defaulting to the conventions for the OS determined when it is built.

    A primarily-Unix user might think that just grabbing the bits after the last dot would be naive behavior!

  3. I suppose the heart of the matter is that we’re not dealing with LaTeX per se but the graphics package. I doubt LaTeX it self would have done this. I think it would have been better for the package to disregard file extensions entirely, following Unix conventions, rather than doing something that’s not going to make Unix or Windows people happy.

  4. You are best off avoiding suffixes entirely, that way if you have multiple versions of a file (a .eps and a .png, say) includegraphics will pick the right one for you depending on context.

    In otherwords includegraphics{file} will find file.png if you are in pdflatex, and file.eps if you are in latex. It sounds a bit wonky, but turns out to work well in complicated situations where you may want do generate different output from related files.

  5. I ran into this same issue yesterday with input{file}, so I don’t think it’s only a problem with the graphics package.

  6. My vote goes for feature. IIRC TeX also runs on naive platforms, like DOS. Maybe that’s for compatibility reasons…

  7. I was expecting this to be about the -/_ bugginess in graphicx — always go with hyphens, when possible; underscores can lead to unexpected and difficult to debug problems (at least on my Mac OS X Snow Leopard with latest TeX dist).

  8. Hello,
    I am a new user of Beamer. I found, I can include 5 (.png) graphics only (total size of those are 1MB).
    Is there any way to include more than 1MB?
    Can you please tell how can I include more ?

  9. It’s tricky anyway (e.g. what about file.png.gz etc.). But one should’t provide the extension to includegraphics (let the output driver do its job). It makes the code less portable across different output formats.

Comments are closed.