2

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?

Vilkas
  • 23
  • 1
    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 07 '21 at 13:32
  • 1
    @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 07 '21 at 14:46
  • You could probably write a \DeclareGraphicsRule to do the conversion in-place. – Marijn Jan 07 '21 at 14:48
  • In fact an example of exactly your use case is given on https://latexref.xyz/_005cDeclareGraphicsRule.html at the end of the page. – Marijn Jan 07 '21 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 07 '21 at 14:56
  • No I don't know a document. I also don't know when the support was dropped, you probably would have to ask on the texlive list. But the topic came up in december, and we discussed it a bit. See e.g. David's comment here: https://tex.stackexchange.com/questions/574562/inclusion-of-graphics-with-on-the-fly-conversion-using-xetex?noredirect=1#comment1447352_574562 – Ulrike Fischer Jan 07 '21 at 14:59
  • @UlrikeFischer I see, I thought graphicsrules were performed using shell-escape by LaTeX during processing before a dvi is created or converted, I guess I was mistaken. But then maybe https://tex.stackexchange.com/questions/66943/using-macros-in-declaregraphicsrule-statement-using-shell-command would still work, i.e., \epstopdfDeclareGraphicsRule or \noexpand\epstopdfcall, because they don't use backticks? – Marijn Jan 07 '21 at 15:21
  • @UlrikeFischer I see, thank you for the link to a related question. As far as I understand, David's comment only states that the --shell--escape feature has never worked in xetex, but nothing about it recently breaking or being disabled.

    I understand the dangers of --shell-escape, but I would be willing to use it on my documents in a sandbox environment. However, currently the compilation crashes seemingly due to the special handling of the .eps.gz extension. Do you think it is something worth reporting?

     – Vilkas Jan 07 '21 at 16:50
  • @UlrikeFischer nope this is a bug – David Carlisle Jan 07 '21 at 16:51
  • This should be fixed for the next (May) release: https://github.com/latex3/latex2e/pull/520 – Phelype Oleinik Mar 05 '21 at 02:08

2 Answers2

0

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}}
David Carlisle
  • 757,742
  • 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 08 '21 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 08 '21 at 15:07
  • Great, thank you. :) – Vilkas Jan 08 '21 at 15:20
0

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.

Maxim
  • 101