grffile does not work with LuaTeX any more

[e-kwsm]

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]

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

[mrpiggi]

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]

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 <https://github.com/ho-tex/oberdiek/issues/73?email_source=notifications&email_token=AAJVYAUDC4ABFGUKBFWHQG3QNNGQPA5CNFSM4I6DCVG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAQWI3Y#issuecomment-539059311>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJVYARJ36BGPYFHGNPPWYDQNNGQPANCNFSM4I6DCVGQ> .

[mrpiggi]

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]

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 <https://github.com/ho-tex/oberdiek/issues/73?email_source=notifications&email_token=AAJVYARDSIBAWQUXMAGCF6TQNNL5NA5CNFSM4I6DCVG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAQ35RI#issuecomment-539082437>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJVYARWRBLETW5LDVXFWMLQNNL5NANCNFSM4I6DCVGQ> .

[mrpiggi]

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]

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 <https://github.com/ho-tex/oberdiek/issues/73?email_source=notifications&email_token=AAJVYAST4YGUUZPPZFPUVVLQNO3MBA5CNFSM4I6DCVG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEASBFZI#issuecomment-539235045>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJVYASKUREVVWHK4XNU2Z3QNO3MBANCNFSM4I6DCVGQ> .

[maxnoe]

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]

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 <https://github.com/ho-tex/oberdiek/issues/73?email_source=notifications&email_token=AAJVYAR6AFDBNPVQMTXPEO3QNR72DA5CNFSM4I6DCVG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAUCC4Y#issuecomment-539500915>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJVYARBJMKIACUSH6YBIBTQNR72DANCNFSM4I6DCVGQ> .

[kevinvalk]

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

[davidcarlisle]

@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]

@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]

@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]

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]

@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.

[davidcarlisle]

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