2019-10-01 graphics release breaks formerly used {foo.bar}.png syntax for filenames with multiple dots

[jfbu]

This seems to be partially under discussion at the grffile tracker and possibly elsewhere at some Q&A site but I did not find it here and I believe it deserves its own ticket because it is unrelated to grffile. The problem is for documents not using grffie but only graphicx and syntax such as \includegraphics{{foo.bar}.png}.

Is there a workaround input syntax which will work with older LaTeX kernels? Or is it planned to modify things in an upcoming Patch Release? If acceptance of this input syntax is only to come back at a next LaTeX relase, as this from above linked issue seems to indicate,

Multiple dots is a separate thing I hope to support that directly in
graphicx but not in this release,

it means that derivatives using LaTeX will have to provide dedicated workaround because there will be at some point in future some Linux distros which might happen to use 2019-10-01. If syntax becomes usable again in a soon upcoming Patch Release, then this means production tools can consider not do anything and tell users in future "bad luck, update your LaTeX". But if multiple months are needed before LaTeX update this becomes problematic.

[davidcarlisle]

I hope to have a PL2 out this week, but there are still interactions with assorted packages to check, the workaround

\documentclass{article}
\makeatletter
\def\set@curr@file#1{\def\@curr@file{#1}}
\makeatother

\usepackage{graphicx}
\begin{document}

\includegraphics{{foo.bar}.png}

\end{document}

basically undoes the change (removing support for non-ascii filenames) but makes your example work.

[jfbu]

Thanks @davidcarlisle for workaround. I understand the situation is complex. Being lazy I hope all things will get resolved at my end (Sphinx documentation tool) by doing nothing but wait :)

[davidcarlisle]

In the unquote branch of the repository

\includegraphics{{foo.bar}.png}

works like

\includegraphics{foo.bar.png}

(both include foo.bar.png)

what I'm currently wondering is whether

\includegraphics{foo.bar}

should also work, adding the default .png extension.

Currently, as before, it sees foo.bar as having an unknown .bar extension so does not try adding extensions but I think it could try adding extensions before giving the file not found error.

[FrankMittelbach]

I would say only when that doesn't unnecessarily complicates the code. It doesn't seem unreasonable to ask in case of a multi-dot file for providing an extension. Okay that doesn't allow different default extensions with different setups but ...

[davidcarlisle]

@FrankMittelbach proof is in the pudding as my mum would say... I haven't tried it yet but I think it's just re-arranging the existing code rather than complicating it. The test to try the extensions is there but currently only activated if the filename parse found no extension so it might even be simpler, just removing that test.

But as you say if it ends up being complicated forcing the extension to be explicit these days is not really a big deal as all the web2c implementations share graphics capabilities, it's not like sharing a document between emtex and textures and unix tex when there were no file formats in common. If it's a pdftex document and you use .png (or .pdf or whatever) then it will work everywhere so you don't gain anything by omitting the extension.

[jfbu]

Thanks for the quick PL2 fix. Now {img.foo}.png works again and also {name with spaces.foo}.png thus I closed sphinx-doc/sphinx#6777 and I presume I could close this issue too, but I don't know what is practice here and if your prefer the LaTeX team to do that.

(for people reading the thread, I add the precision of course known to the LaTeX maintainers that {name with spaces.foo}.png failed with TL2018, although the graphics correctly got incorporated into the PDF, part of its filename ended in token stream and also there was a LaTeX warning about missing file)

[davidcarlisle]

Thanks for the confirmation

[davidcarlisle]

@jfbu note that you don't need the braces (latex explicitly drops them so they work for compatibility reasons)

\includegraphics{{name with spaces.foo}.png}

can be more naturally written as

\includegraphics{name with spaces.foo.png}

[jfbu]

Thanks @davidcarlisle for the additional explanations. But we have to support older LaTeX too (currently we require TL2015 or TL2015 based distros). Besides the case with spaces in filenames of image files remains a bit theoretical I believe for Sphinx because brief test shows they get trimmed out early :) (possibly by DocUtils, I have to checked), and basically we don't support this yet. The support for non-ascii is definitly a very good thing and will motivate us to encourage people to use the newest LaTeX which brings this feature.

[jfbu]

@davidcarlisle @FrankMittelbach Hi David, Frank, for some reason (sphinx-doc/sphinx#8135 (comment)) I wanted to test this in retrospect as I had forgotten how the error looked like exactly in log file or console output. I tried the roll-back mechanism (by the way I needed to go to tugboat to fetch Frank's paper as the link on latex-project site seems either broken or very slow, perhaps only a temporary problem) but can one roll-back to in-between patch releases ? Here is the summary of my vain, brief, effort:

LaTeX has since a few years a rollback mechanism. I tried using it with manually adding \RequirePackage[2019-10-01]{latexrelease} but there seems to be no way to roll back to earlier than the final patch level. And the roll-back for graphics (called by graphicx) does not go back far enough. Although by digging into its sources I could try \RequirePackage{graphics}[=2017-06-25] [...]. Also, I don't know how to roll-back the pdftex.def driver code.

[jfbu]

The link to Franck's rollback paper at latex-project.org now works. Some quirk I guess at my locale earlier today.

[FrankMittelbach]

The link to Franck's

close :-)

rollback paper at latex-project.org now works. Some quirk I guess at my locale earlier today.

something is wrong with the Dante server hosting the site ... I noticed problems too.

As to rollback: this is an extremly difficult topic and not always really possible for all scenarios (and also an area where one can easily make mistakes, as it is difficult to reliably test). Anyway, on the whole it should work, so if you have a sample file that doesn't work it would be good to see that --- even if in the end we might have to say, sorry doesn't work.

(not sure if it will be possible to roll back pdftex.def stuff though (or at least not easy)

[jfbu]

The link to Franck's

close :-)

sorry! I had it right the first time :-)

rollback paper at latex-project.org now works. Some quirk I guess at my locale earlier today.

something is wrong with the Dante server hosting the site ... I noticed problems too.

ok

As to rollback: this is an extremly difficult topic and not always really possible for all scenarios (and also an area where one can easily make mistakes, as it is difficult to reliably test). Anyway, on the whole it should work, so if you have a sample file that doesn't work it would be good to see that --- even if in the end we might have to say, sorry doesn't work.

I was trying to emulate LaTeX 2019-10-01 before PL2. Is this at all possible with latexrelease mechanism? I was aiming at seeing how was back then the build error when using \includegraphics{{braced}.png} in order to say to some person with this version of LaTeX/graphics that indeed I could reproduce the error. And that fix was to update LaTeX installation.

[jfbu]

There is always the option of using the git repo and checkout a suitable version, now that I scratch my brain. But I am a bit rusty here. Perhaps I should give it a try.

[FrankMittelbach]

The link to Franck's

close :-)

sorry! I had it right the first time :-)

don't worry about it :-) .. it only reminded me of the first French printing of the LaTeX Companion, where they had to throw away the whole print run of the covers because they made that mistake ...

I was trying to emulate LaTeX 2019-10-01 before PL2. Is this at all possible with latexrelease mechanism? I was aiming at seeing how was back then the build error when using \includegraphics{{braced}.png} in order to say to some person with this version of LaTeX/graphics that indeed I could reproduce the error. And that fix was to update LaTeX installation.

ahh, no we usually don't do rollbacks to such intermediate (broken) versions. It would be a logistic nightmare to try and do that and if something is badly broken there is the expectation that there aren't many documents relying (through workarounds) on the broken behavior. That is much different to a bug being in for several years or several releases.

[FrankMittelbach]

There is always the option of using the git repo and checkout a suitable version, now that I scratch my brain. But I am a bit rusty here. Perhaps I should give it a try.

you can check it out, then run

l3build install

which puts the ready to use version into your local tree (you still have to make a format though)

but don't forget to get rid of the format and the local tree stuff (l3build uninstallfor the latter)

[jfbu]

@FrankMittelbach perfect as this allowed me to recreate the error with a checkout of LaTeX 2019-10-01 prior to patch releases.

LaTeX Warning: File `{img_file}.png' not found on input line 102.

! Package pdftex.def Error: File `"""{img_file}".png' not found: using draft se
tting.

See the pdftex.def package documentation for explanation.

However, I had to create a pdflatex-dev format after realizing a latex-dev hierarchy was created in my user texmf and I then issued pdflatex-dev test to generate the above error. Thanks! It was not that complicated but your mentoring helped ;-)

[jfbu]

it seems I had to manually delete a texmf/makeindex repertory, or some left-over from something else.

[FrankMittelbach]

Am 17.01.21 um 19:09 schrieb Jean-François B.:

However, I had to create a |pdflatex-dev| format after realizing a |latex-dev| hierarchy was created in my user |texmf| and I then issued |pdflatex-dev test| to generate the above error. Thanks! It was not that complicated but your mentoring helped ;-)

yeah it is not really a user procedure but I thought you'll manage (and don't forget to get rid of the format again, otherwise you will later wonder why things behave strangely)