GeezerVison

Is this ready for review, now that #20715 has been merged?

This is failing on Ubuntu 22.04 and Windows but passing on 24.04 and Mac. Here's one failing image (test_usetex_pdf.png, so converted from pdf to png on the test system).

This looks like the font is entirely broken. The expected image similarly converted looks like this:

Strangely enough, the generated pdf file looks fine on my Mac.

I can repeat the error running on an Ubuntu 22.04 docker image:

GPL Ghostscript 9.55.0 (2021-09-27)
Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
see the file COPYING for details.
Processing pages 1 through 1.
Page 1
   **** Error: can't process embedded font stream,
        attempting to load the font using its name.
               Output may be incorrect.
Querying operating system for font files...
Substituting font Helvetica for MPLAAD+CMR17.
Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4467044 2957798 6795968 5451925 4 done.
   **** Error: can't process embedded font stream,
        attempting to load the font using its name.
               Output may be incorrect.
Substituting font Helvetica for MPLAAC+CMR12.
   **** Error: can't process embedded font stream,
        attempting to load the font using its name.
               Output may be incorrect.
Substituting font Helvetica for MPLAAA+CMEX10.
   **** Error: can't process embedded font stream,
        attempting to load the font using its name.
               Output may be incorrect.
Substituting font Helvetica-Oblique for MPLAAB+CMMI12.
Loading NimbusSans-Italic font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Italic... 4534308 3175939 7138400 5761600 4 done.

The subsetting is wrong in some way that breaks Ghostscript 9.55 but not the viewer in macOS or the newer Ghostscript in Ubuntu 24.04. (Ghostscript 9.56 has a completely rewritten PDF interpreter.)

I hope I found the culprit... I was writing an extra delimiter between the Subrs and the Charstrings when one was already there.

It looks like you'll need to install heuristica and DejaVuSans texlive packages in .github/workflows/tests.yml to get those new tests running.

It looks like you'll need to install heuristica and DejaVuSans texlive packages in .github/workflows/tests.yml to get those new tests running.

Yes, but Debian (and hence Ubuntu) bundles them into texlive-fonts-extra with a large number of other fonts. Not sure that slowing down all test runners is worth it, but perhaps we could do it in just one runner?

[Edit: Or we could see if we can install packages via tlmgr. Debian recommends against it but I don't think we need to worry about messing with package dependencies in a CI script.]

Here are the times for the "Install OS dependencies" step in the previous 3 commits:

And for the 2 last commits with the additional 1 or 2 packages:

It looks like it would add about ~1m per job?

It's unfortunate we aren't running on Fedora, where all texlive packages are available individually (though no guarantee that'd be faster.)

Some ideas:

• install TeX without using the Ubuntu packages, with e.g. TinyTeX (not guaranteed to be faster)
• run the tests inside Docker, build images in phases so the base OS and TeX are installed in advance, store the images in GitHub Container Registry (can almost certainly shave off several minutes off the build time, at the cost of some complexity and may need to pay GitHub for the GHCR storage)
• set up TeX only in a subset of the test runners, or dedicate some runners to TeX tests only (the latter would increase parallelism and might reduce wall-clock time, but Amdahl's law applies)

I think option 3 (only run on a subset). I would go with the newest Python.

Should be able to set an optional addition in the matrix just like we do with matrix.extra-requirements.

I moved the packages texlive-latex-extra, texlive-fonts-extra and texlive-lang-cyrillic to one runner only. (The texlive-latex-extra package has been included for a long time and I'm not sure which exact LaTeX dependencies are used by our tests.)

Complete run times:

For comparison, a recent commit on main:

In this case it seems to have added a little under two minutes to that runner, including both the time taken to install and the extra tests run. There seems to be quite a bit of variation from run to run, and most of the overall increase is due to the macos builders where I don't think we even install TeX.

https://matplotlib.org/devdocs/install/dependencies.html#latex-dependencies says it's for import, sfmath, and type1cm, and type1cm is used unconditionally in the preamble. According to the log, texlive-latex-extra is already being installed by dependency of something else which is why it didn't break, so I don't think it makes sense to move it to the extras job only. It should stay for explicitness in all jobs.

texlive-latex-extra is already being installed by dependency of something else which is why it didn't break, so I don't think it makes sense to move it to the extras job only. It should stay for explicitness in all jobs.

Agreed! I changed that package back.

Closes #127.

Congrats on closing a 3-digit issue.