# grffile does not work with LuaTeX any more #1

Closed
opened this issue Oct 7, 2019 · 16 comments

## Brief outline of the bug

latex3/latex2e@7fae7e8 breaks backward-compatibility: grffile does not work with LuaLaTeX, while it still works with pdfLaTeX and XeLaTeX.

## Minimal example showing the bug

\documentclass{article}
\usepackage{grffile}
\usepackage{graphicx}
\begin{document}
\includegraphics{example-image-a.pdf}
\end{document}

LuaLaTeX emits the following error:

(/opt/texlive/2019/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg))

LaTeX Warning: File example-image-a.pdf' not found on input line 5.

! error:  (file """example-image-a".pdf) (pdf backend): cannot find image file
'"""example-image-a".pdf'
!  ==> Fatal error occurred, no output PDF file produced!


OTOH pdfLaTeX and XeLaTeX can find the image.

My environment:

• lualatex: 1.10.0 (TeX Live 2019)
• pdflatex: 3.14159265-2.6-1.40.20 (TeX Live 2019)
• xelatex: 3.14159265-2.6-0.999991 (TeX Live 2019)
• grffile: 2017/06/30 v1.18
• graphics: 2019/07/20 v1.3b

## Log file (required) and possibly PDF file

mwe.log

### davidcarlisle commented Oct 7, 2019

 Thanks for the report, I can confirm the issue, we'll update as soon as possible.

### mrpiggi commented Oct 7, 2019

 Probably related to this issue. \documentclass{article} \usepackage{graphicx} \begin{document} \includegraphics{{example-image-a}.pdf} \end{document} Encapsulating the file name in braces made it possible to use spaces within file names. With the latest kernel, this doesn't work anymore for all three mentioned engines.

### davidcarlisle commented Oct 7, 2019

 It's due to related changes but slightly different I think: note spaces (and utf-8 non ascii characters) should work with no need for {} in the current release, we will probably make \includegraphics{{example-image-a}.pdf} work as well, although it mostly worked by accident previously and the syntactically similar \input{{example-image-a}.tex} would not drop the braces and so would input a file with literally the name {example-image-a}.tex \includegraphics and \input are (now) going through the same code to make spaces and utf-8 characters safe, so dropping braces in one case and not the other has some challenges but we'll see what we can do... … On Mon, 7 Oct 2019 at 16:11, Falk Hanisch ***@***.***> wrote: Probably related to this issue. \documentclass{article}\usepackage{graphicx}\begin{document}\includegraphics{{example-image-a}.pdf}\end{document} Encapsulating the file name in braces made it possible to use spaces within file names. With the latest kernel, this doesn't work anymore for all three mentioned engines. — You are receiving this because you commented. Reply to this email directly, view it on GitHub , or mute the thread .

### mrpiggi commented Oct 7, 2019

 Regrettably, encapsulation in braces has been necessary for file names with multiple dots as well and is now broken with the latest kernel version. None of the two variants can currently be used: \includegraphics{example.image.pdf} \includegraphics{{example.image}.pdf}

### davidcarlisle commented Oct 7, 2019

 yes sure. If you do not need non-ascii filenames then you can add \makeatletter \def\set@curr@file#1{\def\@Curr@file{#1}} \makeatother after loading graphicx and the old behaviour should come back, but that of course disables the new code to allow accented characters (or non latin scripts) in filenames. Multiple dots is a separate thing I hope to support that directly in graphicx but not in this release, so the intention this time round was that grffile was still needed, but it seems to have broken, Not sure quite what we will change yet but we will certainly change something in the next day or so. Sorry about the inconvenience … On Mon, 7 Oct 2019 at 16:57, Falk Hanisch ***@***.***> wrote: Regrettably, encapsulation in braces has been necessary for file names with multiple dots as well and is now broken with the latest kernel version. None of the two variants can currently be used: \includegraphics{example.image.pdf}\includegraphics{{example.image}.pdf} — You are receiving this because you commented. Reply to this email directly, view it on GitHub , or mute the thread .

### mrpiggi commented Oct 7, 2019

 For me, everything is fine with the spaces. In fact, I am pleased that the matter has now been taken over by the kernel. As for the issue with the multiple dots in the filename, it might make sense to adjust \filename@simple in order to parse not for the first but for the last dot in the filename? Anything found before the last dot could be appended to \filename@base. But I have no idea if that would possibly break something elsewhere.

### davidcarlisle commented Oct 7, 2019

 Yes that's basically the plan (didn't have enough token memory available to do that back then) also though it requires some changes to the logic throughout the package as normally the recommendation is to miss off the extension, so if you want to support a.b.c.png but allow \includegraphics{a.b.c} then that means that the package needs to take the "try the graphics extension list" path even if the supplied argument apparently has an extension. So there are small or not so small changes throughout the package, and as ever need to (try) not to break third party extension packages, but I'll see what I can do, There is also the original use case for taking the first dot which is file.eps.gz which you want to handle as .eps..gz although that is not the dominant format it was when the graphics package was written. … On Mon, 7 Oct 2019 at 23:42, Falk Hanisch ***@***.***> wrote: For me, everything is fine with the spaces. In fact, I am pleased that the matter has now been taken over by the kernel. As for the issue with the multiple dots in the filename, it might make sense to adjust ***@***.*** in order to parse not for the first but for the last dot in the filename? Anything found before the last dot could be appended to ***@***.*** But I have no idea if that would possibly break something elsewhere. — You are receiving this because you commented. Reply to this email directly, view it on GitHub , or mute the thread .

### MaxNoe commented Oct 8, 2019

 Wouldn't it make more sense to have a list of supported formats and check for those? If one of the supported ones is not in the filename, check if the filename + the supported extensions exist. e.g. ['.png', '.jpg', '.pdf', 'eps.gz'] and file.a.jpg' would result in just looking for jpg but file.a would result in checking for file.a.png , file.a.jpg and so on... If this feature is really wished, for my part I never understood why leaving out the extension was ever supported!

### davidcarlisle commented Oct 8, 2019

 On Tue, 8 Oct 2019 at 13:59, Maximilian Nöthe ***@***.***> wrote: Wouldn't it make more sense to have a list of supported formats and check for those? If one of the supported ones is not in the filename, check if the filename + the supported extensions exist. e.g. ['.png', '.jpg', '.pdf', 'eps.gz'] and file.a.jpg' would result in just looking for jpg but file.a would result in checking for file.a.png , file.a.jpg and so on... something like that yes, as you probably know each back end declares a list of supported extensions already. If this feature is really wished, for my part I never understood why leaving out the extension was ever supported! Possibly less important than it used to be but that was essential in providing portable documents originally. If some drivers support eps, some pdf, some png some jpg some Mac specific picture formats and so on being able to have \includegraphics{file} in the document and then have textures use file.pict, dvips use file.eps, pdflatex use file.pdf etc was one of the main and most used features of the package. This is why the standard advice has always been to omit the extension. David — … You are receiving this because you commented. Reply to this email directly, view it on GitHub , or mute the thread .

### kevinvalk commented Oct 17, 2019

 I have the exact same issue as op. Please let me know if I can provide additional information for fixing this issue.

### davidcarlisle commented Oct 17, 2019

 @kevinvalk sorry about that, I'll try to get something posted this weekend. So long as you don't have spaces in your filenames you can use the following to make the quotes go, but they are added to allow spaces in filenames (but conflicting at present with code that grffile was already adding to do the same.) It's clear where the code goes wrong but fixing it in a way that's compatible with all combinations of packages being loaded or not loaded or loaded in different orders is a bit tiresome. Medium term plan is to get graphicx to support multiple dots as well as spaces, then make grfffile package a no-op legacy stub which will cut down the number of different interactions, but that may need to wait for a later release. \documentclass{article} \usepackage{grffile} \usepackage{graphicx} \makeatletter \let\quote@name\unquote@name \makeatother \begin{document} \includegraphics{example-image-a.pdf} \end{document} 

### kevinvalk commented Oct 17, 2019

 @davidcarlisle, thanks a bunch! That is a fine temporary workaround. I am using this in combination with the underscores package (https://ctan.org/pkg/underscore?lang=en). I know this package is generally considered a bad idea, but to make a long story short, it is more important that users can just write "_" without thinking about it. The [strings] option is broken and cannot be used. The grffile package has a side effect to properly handle the "_" in the includegraphics commands when the underscore package is in use. I will have to do some thinking about how to properly fix this. Once again, thanks!

### davidcarlisle commented Oct 17, 2019

 @kevinvalk one of the main changes (in the set of changes that broke grffile) is that active characters for UTF-8 accented character are all now safe to use in filenames and apply \string to themselves, so if the package (or a patch to it) made an active _ do \ifincsname\string_\else whatever you were going to do\fi then you will be able to use the _ in filenames (for \input as well as \includegraphics) even when active.

### wilx commented Oct 28, 2019

 I understand sometimes things get broken in process of refactoring and improving things. However, this is taking too long now. Whatever is the root cause, all of my documents are broken right now, unless I employ one of the workarounds. I find this unacceptable. I know this is volunteer project and all but this state cannot be for much longer. Please fix it one way or another or revert the breaking changes.

### davidcarlisle commented Oct 28, 2019

 @wilx as noted in tex.sx, but I'll put here for the record, unless your graphics files have multiple dots then simply not using grffile is by far the best option.
referenced this issue in jgm/pandoc Oct 30, 2019
 Remove include of grffile from default latex template. 
 4d5fd9e 
This package is needed for proper handling of image filenames
containing periods (in addition to the period before the
extension).

Unfortunately, grffile breaks in the latest texlive update.
Until a fix is released (see ho-tex/oberdiek#73) it seems best
to remove this from the default template.

This may cause problems if you have filenames with periods.
The workaround is to put \usepackage{grffile} in header-includes,
and be sure you're using an older version of texlive packages.

See #5848. We will leave that issue open to remind us to
check upstream, and restore grffile when it's possible to
do so.
transferred this issue from ho-tex/oberdiek Nov 7, 2019

### davidcarlisle commented Nov 7, 2019

 grffile (and this issue) have now been split off from the oberdiek bundle. grffile 2.0 has just been uploaded to CTAN and by default just loads the standard graphicx package, all handling of multiple dots and spaces is now in the base latex code and should work as expected with LaTeX2e <2019-10-01> patch level 2
referenced this issue Nov 10, 2019
referenced this issue Nov 11, 2019