Bug#259390: tetex-bin: Mistake in processing a filename
severity 259390 wishlist
retitle 259390 graphics package can't handle filenames of the form: name.xxx.yyy.$extension
tags 259390 + wontfix
stop
On 14.07.04 Ajay Shah (ajayshah@mayin.org) wrote:
> > That file a.z.pdf I just touched and he bombs out with that
> > message. So I guess graphics parses the filename from the
> > beginning to the end to get the extension and starts reading as
> > soon as the first dot is found. I'll contact upstream about that.
> > Meanwhile you could just rename the file if it's acceptable for
> > you...
>
> I'm perfectly fine with the workaround. (I shifted to a_z.pdf
> myself). But it's a blemish, and it would be nice if you would push
> the developers to solve it. :-) Thanks,
>
OK. I've got some answers from members of the german TeX group.
First I describe some possible workarounds. I assume the file name is
a.z.eps or a.z.pdf (depending of if we're using LaTeX or pdfLaTeX).
The number of dots of course can be raised.
1.
\documentclass{minimal}
\usepackage{graphicx}
\begin{document}
\newcommand\DOT{.}
\includegraphics{a\DOT z}
\end{document}
2.
\documentclass{minimal}
\usepackage{pgf}
\begin{document}
\pgfdeclareimage{HUGO}{a.z}
\pgfuseimage{HUGO}
\end{document}
I don't know anything about possible options of the package pgf.
Please have a look at the docs. It needs the package xcolor.
3.
\documentclass{minimal}
\usepackage{graphicx}
\usepackage{ifpdf}
\begin{document}
\ifpdf
\includegraphics[type=pdf,ext=.pdf,read=.pdf]{a.z}
\else
\includegraphics[type=eps,ext=.eps,read=.eps]{a.z}
\fi
\end{document}
The last seems the best solution to me. Now the ansers I've got. I
asked, why LaTeX is able to handle the case "filename is a.z.z and
\includegraphics{a.z.z}":
<snip>
dvips has an default rule, that every unknown kind of graphics is
treated as eps.
<snap>
So if you do that (and a.z.z is a link to a.z.z.eps) he'll read a.z.z
instead of a.z.z.eps.
<snip>
In pdfLaTeX that default rule does not exist, as different kind of
graphics can be feed to pdfTeX. (...) It would make sense to define a
default rule for MetaPost-Files (.mps), cause they can be recognized,
even if the extension is not .mps.
Is there a file "a.z" the parsers treats the "a" as name and the ".z"
as the extension. ".z" is neither defined in pdftex.def nor in
dvips.def. Hence in LaTeX the default rule is applied, pdfLaTeX has
no default rule, hence the error message.
(...) unfortunately the parser treats everything after the first dot
as extension. Because there are complex extension allowed ".eps.gz",
"ps.z" (IIRC) dots in the name are not easy to handle. (...)
A possible solution could be to parse for know extensions.
Unfortunately this is a hard task to do in TeX. (...)
The easiest work around is to mask the dots in the file name to TeX.
This is described in the first 2 examples.
<snap>
<snip>
The parsing is done using low level LaTeX-Kernel macros
\filename@parse. They are called by graphics.sty.
<snap>
As I assume this to be a missing feature instead of a bug I'm setting
the severity to wishlist. We (in the DBTS) probably won't fix it, so
I tag it wontfix. We'll come back to it, if the described situation
will change, but I have doubt that this will happen.
Sorry, no positivs answer.
Just for the records. The thread is in german:
<40a3dc.ep5.ln@preusse-16223.user.cis.dfn.de>
H.
--
sigmentation fault
Reply to: