Pandoc: Images not included with Xelatex and new version of graphicx

[louis-martin]

Using MacTex distribution and graphicx version higher than 51733

the problem exist only for Xelatex engine.

In the tex file generated by Pandoc, if the line

\usepackage{graphicx,grffile}

is replace by

\usepackage{graphicx}

everything is OK

[mb21]

But we probably would want to keep the functionality of grffile, right? Is this only in macOS Catalina, or..? same problem: https://stackoverflow.com/questions/58466912/no-images-in-pdf-generated-by-pandoc-xelatex-engine where someone said reinstalling xelatex fixes this.

[louis-martin]

It is on macOS Mohave.

Reinstalling MacTex seems to fix the problem.

[bogdanni]

Struggling with the same problem (thank you for the workaround!), version 52372. Not only Catalina, can be reproduced with e.g., TinyTex on Linux. The reinstallation probably downgrades the version of the package.

[iandol]

For those who reinstalled to solve this, what happens when you upgrade Tex (sudo tlmgr update --all -- I assume the error returns)?

The guaranteed workaround is just to make a modified latex template removing grffile until this gets fixed upstream...

[jgm]

We need two pieces of information:

1. Why does the template include grffile? What would break if we removed it?
2. Why does grffile cause a problem with xelatex with current versions of texlive packages? Is the bug in grffile or somewhere else? Is it going to be fixed upstream, and can we get a link to the relevant issue?

[jgm]

grffile include was added in commit c5acaec3b5c0d0bac4ac23ae2cf72336140b7d96 in response to #2074.

[jgm]

Looks like we can solve the problem without grffile by adding curly braces around the image filename if it contains periods: e.g. raster_190.09.png -> {raster_190.09}.png.
So that's a good solution I think:

• [ ] change LaTeX writer to add the curly braces when needed
• [ ] remove grffile from default latex / beamer template.

[wilx]

This issue is relevant also to LuaLaTeX. See also ho-tex/oberdiek#73.

[jgm]

Hm. The solution recommended in the comment on issue #2074 doesn't work.
With

\includegraphics{{la.lune}.jpg}

I get

! LaTeX Error: Unknown graphics extension: .lune}.jpg.

Back to the drawing boardd.

[jgm]

Upstream issue for grffile: https://github.com/ho-tex/oberdiek/issues/73

[jgm]

Okay, now that I've read https://github.com/ho-tex/oberdiek/issues/73 I can see that

• changes to the kernel have made it the case that the trick of putting curly braces around the filename no longer works
• grffile no longer works either
• it's not clear when grffile will be updated

I think the thing to do is:

1. for now, remove grffile from the default template.
2. leave this issue open pending changes upstream; when grffile is fixed we can put it back

Change 1 will break things for those who have dots in filenames (not just between the filename and tex extension), but this is presumably not that common. Hopefully it won't be long before the upstream issue is fixed.

[e-kwsm]

Hm. The solution recommended in the comment on issue #2074 doesn't work.
With

\includegraphics{{la.lune}.jpg}

I get

! LaTeX Error: Unknown graphics extension: .lune}.jpg.

Back to the drawing boardd.

The issue is due to graphicx rather than grffile: latex3/latex2e#204

[jgm]

Based on #5862 it seems that removing grffile is still needed for now.
But it's correct that the underlying problem is with graphicx.

[davidcarlisle]

the basic plan is that

\includegraphics{a.b.png}

should work in the core graphics code, with

\includegraphics{{a.b}.png}

also working for backward compatibility (the braces are simply discarded)

This is implemented in the core latex release unquote branch working on a <2019-10-01> Patch level 2 latex release hopefully in a day or so.

https://github.com/latex3/latex2e/tree/unquote

grffile package had some other (mostly unused) facilities but it was overwhelmingly used for spaces and multiple dots in filenames. spaces already work in the core (it was that change that broke grffile trying to patch to add the same feature) and multiple dots are working on that branch and will work in the main release once a few more issues sorted out, days not months.

Sorry about the inconvenience but the pressure to support spaces (and non ascii characters) in filenames throughout the latex filehandling code became overwhelming really. Most of the changes are in the core latex filehandling, not on the graphics package.
grffile will probably be made an empty-no-op package but with an option to use the package rollback feature to re-instate the old grffile code if some document really needs it, that is

\usepackage{grffile}[=2017/06/30]

if you really need the existing grfflile

[davidcarlisle]

if you want something that works _now_ then I suspect that

\def\set@curr@file#1{\def\@curr@file{#1}}

will work, that undoes all the latex 2019 filehandling changes so you can't use non ascii characters or spaces (in \input or \includegraphics) but it does make things work as before..

https://tex.stackexchange.com/a/512877/1090

Although I haven't actually tried either of the fixes suggested there with pandoc.

[jgm]

@davidcarlisle thanks for commenting here! It's good to know that we won't need to restore grffile in our default template, and that a.b.png will work in \includegraphics.

[davidcarlisle]

latex2e 2019-10-01 patch level 2 went to ctan yesterday so should appear in distributions soon, the following forms should all work just using graphicx (not grffile)

1 \includegraphics{a.b.png}

1b \includegraphics{{a.b}.png} % a.b.png

2 \includegraphics{a.b} % a.b.png

3 \includegraphics{foo bar.png} % "foo bar.png"

4 \includegraphics{foo bar} % "foo bar.png"

{
\graphicspath{{nospace/}}

5 \includegraphics{a.png} % nospace/a.png
}

{
\graphicspath{{space here/}}

6 \includegraphics{a.png} % "space here/a.png"
}

I plan to update grffile (to do nothing by default) once that has propagated to mirrors.

[jgm]

Terrific!