attn @pwuertz

I do remember trying \includegraphics first and having troubles with it, but I don't remember any specifics. It may very well be that those problems are gone now and switching to includegraphics is fine, but we'd have to check the tests on all supported TeX systems to be sure there are no drawbacks.

On the other hand, is there a need to change it at all? I don't know what subimport does, but as written in the preamble comment, the current pgf figures should work perfectly fine with \usepackage{import} and

\import{<path to file>}{<filename>.pgf}

\subimport is also part of the import package, but takes relative paths as the first argument (according to the docs). Now that I tried it, it seems like \import also works with relative paths.

Nonetheless, neither \import nor \subimport work for me (using either pdflatex or lualatex) with \pgfimage, while they do with \includegraphics. I am not the only one with this problem, see e.g. here.

I'd be happy to help with testing.

I'm still puzzled as to why \import won't work anymore, because I certainly tested and used it in the past. Whatever.. this wouldn't be the first thing to be broken by a latex/package upgrade.

I did some tests in replacing pgfimage with includegraphics. Interpolation setting and image clipping seem to work fine nowadays. So no reason not to switch to includegraphics I suppose.

https://tex.stackexchange.com/a/32989 states that \pgfimage uses its own primitives for pdftex, so maybe it was fine for traditional latex, but breaks for pdftex and friends?

Repeated a interpolation and clipping test successfully with pdf-, xe- and lualatex. If there was a problem with \includegraphics back then it appears to be gone now.

I was running tests on my machine using TeX Live 2017. The Travis CI tests, which are running with TeX Live 2013, are failing due to the interpolation parameter in \includegraphics. So back then there really was no alternative to \pgfimage. The question probably is, at which time are we willing to break compatibility with TeX Live 2013?

By the way, Travis uses Ubuntu 14.04 by default, which comes with texlive 2013. If Travis decided to go to the next LTS, 16.04, we could check if texlive 2015 does the job. They seem to be a bit conservative though, 14.04 was declared default in late 2017...

As far as I know, matplotlib 3.0 will require at least Python 3.5. Ubuntu 14.04 has 3.4, so it will not be compatible with mpl 3.0 anyways. Therefore I guess it should be safe to get this fix into mpl 3.0, as not many people will be running Texlive 2013 with Python 3.5+.

Another option would be to add something to rcParams, like rcParams["pgf.graphicscmd"] = "pgfimage" by default, which a user could set to rcParams["pgf.graphicscmd"] = "includegraphics" (or whatever is desired); the default value could be changed in due time.

Btw, I am using Ubuntu 16.04 with Texlive 2015, and \includegraphics works for me.

I also think that 16.04 is a reasonable base to support, but Travis could become a problem here. It sounds like they are not planning on updating Ubuntu base images any time soon. They instead advise on using docker for building custom testing environments.
@tacaswell Are there any plans for the matplotlib CI tests going in this direction or do we stick to whatever Travis declares as default Ubuntu image?

fwiw http://ftp.math.purdue.edu/mirrors/ctan.org/macros/latex/required/graphics/grfguide.pdf states that interpolate support only dates back to 2017/06/01.

I wonder whether a solution like #11228 (conditional tex code) could be adopted.

@anntzer Good idea. Probably a naive question, but: Do TeX packages like graphicx include some kind of version def that could be checked?

Also, there seems to be mixed information concerning interpolation support. The link you posted says that this feature is from 2017, whereas Texlive 2015 already managed to compile a figure using interpolate..

Apparently yes: https://tex.stackexchange.com/a/13309/4101
I agree that the actual minimum version is unfortunately still unclear.

Nice catch.
@lschr You verified that Texlive 2015 was able to handle \includegraphics with interpolate, right? Could you post your \ProvidesPackage line from your graphicx.sty?

In Ubuntu 18.04 /usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty is at 2017/06/01 v1.1a.

It says

\ProvidesPackage{graphicx}
          [2014/10/28 v1.0g  Enhanced LaTeX Graphics (DPC,SPQR)]

Grepping for "interpolate" in my latex tree found a match in /usr/share/texlive/texmf-dist/tex/latex/pdftex-def/pdftex.def, which (apparently) is the graphicx driver for pdftex:

% 2010/09/09 v0.05a (HO)
%  [...]
%  * Option `interpolate' added for bitmaps, see PDF specification.
%    Values are `true' or `false', default is `false'.

So I guess interpolate has been supported for pdflatex for quite some time, but maybe not for plain latex.

If anybody stumbles across this and is looking for a workaround, putting \let\pgfimage\includegraphics in the preamble of my tex file seems to work.

For another work around: If you are programmatically generating the pgf (via a script or scons or some other way) is to add something like

fig.savefig(output)
_, ext = os.path.splitext(output)
if ext == ".pgf":
    with open(output, "r") as fid:
        lines = fid.readlines()

    with open(output, "w") as fid:
        for line in lines:
            fid.write(re.sub(r"\\pgfimage", r"\\includegraphics", line))

to the end of the script.

If anybody stumbles across this and is looking for a workaround, putting \let\pgfimage\includegraphics in the preamble of my tex file seems to work.

Had the same issue today. Neither import nor subimport would fix the problem.

The hacky and simple solution above fixed it though.