re: #12982 (comment)

I am a bit surprised we have not had bug reports on this already.

I think this is because I just made this stricter in #12565... can revert if you want (and remilestoning as 3.1 as that's where that PR lands).

Probably the parsing should do the same thing as font_manager does, i.e. look for substrings matching known weights strings.

Ah, I verified that the parsing is the same in 3.0.2, but not that we got the crash is 3.0.2.

I am much less concerned about this now that it is only on 3.1.

3 is fixed by #12991 , 2 is just annoying but harmless (and only happens on fonts that do not conform to the AFM spec), 1 may be floats written in a locale where , is used as the decimal separator. Internally we are casting this to an int, maybe we want to be using a float internally?

As noted in #12991 (comment) it's really not clear at all to me what the point of this entire afm parsing is (other than for the pdf 14 core fonts, for which we could just hardcode the parsed data anyways)...

Where the issue in 3 came up was in searching for the font closest to what the user asked. I know there has been discussion of moving to just using font-config, but I am not sure that exists on windows.

That's not a fontconfig issue.
The only places we use afm fonts are:

• in the pdf backend, when the pdf.use14corefonts rcparam is set. In that case the 14 core fonts are, well, fixed and we could just store the parsed versions once and for all (we can even leave the afm module in tools/, but not as public API so that we know how the parsed versions are generated).
• in the ps backend, when the ps.useafm rcparam is set. First there's the case of the postscript 35 core fonts, which are essentially like the pdf 14 core fonts. Then we also pick up whatever other afm fonts are installed in the system; but for these, the user needs to have the actual font face (pfa/pfb) to make any use of the generated postscript file, so we may as well directly look for these (and freetype handles them just fine).

Brief reminder: The afm file only contains the metrics and kerning of each glyph (and font metadata), so the pdf/ps backends can use them to position text (with metrics, you know that the string "foo" is 12.34pt tall and 45.67pt wide), but any pdf or ps viewer will need to have access to the glyph outlines (i.e. the shape of each glyph), which are stored in a pfa/pfb file (for example) to actually render the pdf/ps; this is excluding the 14 pdf core fonts / 35 postscript core fonts that each (compliant) pdf/ps renderer is supposed to have embedded.

TLDR: When searching for the closest font to what the user asked, if they want a core font then they are already parsed, otherwise we can just lookup the pfa/pfb files which FreeType handles for us.

Fair enough, do we currently look for the pfa/pfb files?

No, but we could (and likely, on most systems, we won't find anything because they are installed in paths that we don't look for (e.g. the texlive path) -- just like for afm, where at least for my system matplotlib only finds the fonts it ships itself).