Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

grffile does not work with LuaTeX any more #1

Closed
e-kwsm opened this issue Oct 7, 2019 · 16 comments

Comments

@e-kwsm
Copy link

@e-kwsm e-kwsm commented Oct 7, 2019

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

This comment has been minimized.

Copy link
Member

@davidcarlisle davidcarlisle commented Oct 7, 2019

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

@mrpiggi

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

@davidcarlisle davidcarlisle commented Oct 7, 2019

@mrpiggi

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

@davidcarlisle davidcarlisle commented Oct 7, 2019

@mrpiggi

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

@davidcarlisle davidcarlisle commented Oct 7, 2019

@MaxNoe

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

@davidcarlisle davidcarlisle commented Oct 8, 2019

@kevinvalk

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

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

jgm referenced this issue in jgm/pandoc Oct 30, 2019
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.
@davidcarlisle davidcarlisle transferred this issue from ho-tex/oberdiek Nov 7, 2019
@davidcarlisle

This comment has been minimized.

Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.