# Images with the 'eps.gz' extension can no longer be included

The following snippet of code used to work under Linux Mint 19, but fails under Linux Mint 20:

\documentclass{article}
\usepackage{graphicx}

\begin{document}
\includegraphics{test.eps.gz}
\end{document}


Command:

latex test.tex


Log output:

This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) (preloaded format=latex)
restricted \write18 enabled.
entering extended mode
(./test.tex
LaTeX2e <2020-02-02> patch level 2
L3 programming layer <2020-02-14>
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2019/12/20 v1.4l Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty)
(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
(/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty)
(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg)
(/usr/share/texlive/texmf-dist/tex/latex/graphics-def/dvips.def)))
(/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-dvips.def)
No file test.aux.
! TeX capacity exceeded, sorry [input stack size=5000].
\Gin@ext ->\Gin@ext
.gz
l.6 \includegraphics{test.eps.gz}

No pages of output.
Transcript written on test.log.


Under previous LaTeX versions, the image would be properly included or properly reported as missing, i.e.:

...
! LaTeX Error: File test.eps' not found.
...


Have I been doing something wrong all along or is this a new bug that should be properly reported to the development team?

• if I remember right, even without the error it won't work, as the rule for dvips to unpack the gz no longer works (due to new security settings which disables the backtick syntax). So better unpack the file before using it. – Ulrike Fischer Jan 7 at 13:32
• @UlrikeFischer Thank you for the insight about the new security settings, I was not aware of that. Maybe you have reference to a document where this decision is written up in more detail? I will be sure to use the unarchived images in my future work, but I would also like to find a simple workaround if possible to accommodate the already existing projects. – Vilkas Jan 7 at 14:46
• You could probably write a \DeclareGraphicsRule to do the conversion in-place. – Marijn Jan 7 at 14:48
• In fact an example of exactly your use case is given on latexref.xyz/_005cDeclareGraphicsRule.html at the end of the page. – Marijn Jan 7 at 14:49
• @Marijn I was referring to the  gunzip  part: this no longer works. You can't do the conversion in-place any longer unless you enable --shell-escape and use some other command. – Ulrike Fischer Jan 7 at 14:56

This is supposed to work and if you use

\documentclass{article}

\usepackage{graphicx}

\begin{document}

x

\special{PSfile="test.eps.gz"}

y
\end{document}


with latex, dvips, ps2pdf you should find that dvips does uncompress the image. What doesn't work there is that latex will not leave the correct space.

The simplest workaround is to uncompress the eps (if you are using pdflatex rather than latex+dvips then it is anyway better to pre-convert to PDF)

The original somewhat ancient documentation is misleading here as the DeclareGraphicsRule examples were written at a time when dvips allowed you to run any command via the backtick syntax. This has not been allowed for years (decades probably) but it does have a built in rule for .gz files and will uncompress them itself.

This was working, but seems to have broken, probably relating to changes to allow spaces and accented letters in filenames. I'll look later to see if there is a more correct fix.

The graphics rule in the current dvips.def for .eps.gz does not use the  gunzip decompression step, it just passes the filename directly to dvips.

\@namedef{Gin@rule@.eps.gz}#1{{eps}{.eps.bb}{#1}}

• Thank you. I can confirm that the \special approach works. However, since I use a system that scans the tex file for dependencies and generates some of the images on the fly, I will most likely migrate to using unarchived eps files as suggested by you (and previously by @UlrikeFischer). Should I still properly report this issue to the LaTeX developers (i.e. on GitHub) or can this be considered reported given that you are an active contributor to the project? – Vilkas Jan 8 at 14:30
• @Vilkas yes I wasn't suggesting you use the \special just that the basic functionality is there and we broke it sometime in the 2019 timeframe. If that \special` had not worked then the uncompress functionality would have gone from the driver, in which case I could do nothing other than document that fact. I will try to look this weekend at a fix. If I don't do it then you could drop an issue in github so we don't forget but you already reached the main developers:-) – David Carlisle Jan 8 at 15:07
• Great, thank you. :) – Vilkas Jan 8 at 15:20

This is a LaTeX bug which has [supposedly] been fixed just a few days ago, (May 2021), see here the answer by Frank Mittelbach, in the TeX Live 2021.

It will probably take quite some time before this [fixed] release makes it into our Linux distributions. For example, it is not [even] in the unstable Debian Sid yet.