Bug#259390: graphics/3576 Includegraphics has strange filenamerestrictions
On 05.01.05 David Carlisle (david@dcarlisle.demon.co.uk) wrote:
> Hilmar Preusse wrote:
> >On 16.07.04 Ajay Shah (ajayshah@mayin.org) wrote:
Hi,
> >> I would respectfully like to say that from an end-user
> >> perspective, this is a horrible and incompetent bug. I am a geek
> >> and I'm perfectly okay with the workarounds (I just switched
> >> from '.' to '_'). But to tell a lay user that
> >>
> >> \includegraphics{last.year.revenue.pdf}
> >>
> >> will not work: it makes us look incompetent.
> >>
> >> This aspect needs to be communicated to the developers.
> >>
> >
>
> This is a documented restriction rather than a bug. Actually a
> feature of the latex kernel rather than the graphics package.
>
Agreed. In the meantime the bug in our BTS has the severity wishlist.
> The macro \filename@parse is defined when the latex format is made
> (in a system-dependent and user-configurable manner) and is
> responsible for splitting a supplied file name into three
> components: area (directory path) base (base filename) ext (file
> extension. This may be configured in texsys.cfg (see ltdirchk.dtx
> in the base distribution) The default definition in Unix-like
> systems splits the filename by taking the area as everything up to
> the last "/" and the extension as everything after the first "." an
> alternative would be to take the extension as the last "." but that
> would break .ps.gz extensions. A third (less general but possibly
> more friendly in some configurations) would be to recognize some
> special cases such as .gz or .z but otherwise just split on the
> last "."
>
> Normally this has not been an issue, the restriction on "." is
> only on the filename parsing to recognise extensions not on the
> file inclusion. For example a setting of
>
> \DeclareGraphicsRule{*}{pdf}{*}{}
>
> would make pdflatex default to pdf inclusion rather than giving an
> unknown type error. Your example quoted above would then work.
>
> Probably this should be in pdftex.def (dvips.def defaults to eps
> inclusion for similar reasons) or it can be given in a document
> preamble or graphics.cfg file.
>
Thanks for the hint! What is the disadvantage of that solution? That
pdftex after that knows only pdf files? That compressed files are not
recognized any more?
> > Heiko Oberdiek was so kind to write a workaround I attach here.
> >
> This would be interesting code to publish as a ctan package,
> however I think that it is too extensive a change to the core latex
> kernel filename handling. (for latex2e).
>
Well I wouldn't agree on putting that code into the LaTeX2e kernel,
as it is nearly untested (at least by me). How about trying to put
that code into LaTeX3? That one has IIRC still the status
experimental.
> In particular the code to handle spaces in filenames looks rather
> dangerous, in addition with the handling by various dvi drivers (as
> noted in the comments) there is the problem that the graphics
> package uses \read to detect that a file does (or does not) exist
> and in most TeX implementations \read uses space to terminate the
> file name, and this can not be changed by the macro package.
>
As Heiko himself writes in the code, that TeX itself is not able to
handle filenames with spaces, I'd suggest to simply drop "support"
for files with spaces in the filename. It is rather dangerous I
guess.
> The general issue of handling non ascii filenames and interfacing
> with inputenc and babel input conventions is an important one but
> should be handled in a general package so that it works for \input
> and other file interactions not just \includegraphics. Adding
> specific code just for \includegraphics would complicate any such
> general package.
>
See my comment above: one could think about, putting the code into
experimental. As long as this is not done, one could deliver that
special package (minus that "nofilecheck") as add on to graphics,
mark as experimental and document that anywhere.
Kind Regards and thanks,
Hilmar Preuße
--
http://www.hilmar-preusse.de.vu/
Reply to: