GeezerVison

Thank you for opening your first PR into Matplotlib!

If you have not heard from us in a week or so, please leave a new comment below and that should bring it to our attention. Most of our reviewers are volunteers and sometimes things fall through the cracks.

You can also join us on gitter for real-time discussion.

For details on testing, writing docs, and our review process, please see the developer guide.
Please let us know if (and how) you use AI, it will help us give you better feedback on your PR.

We strive to be a welcoming and open project. Please follow our Code of Conduct.

This seems reasonable on a quick read to me, but @QuLogic needs to review this.

It probably makes sense to add more names where available, but I'm uncertain whether, e.g., Ubuntu Light should be regular weight, or a Light suffix should trigger a lower weight instead.

IIRC, @anntzer last looked at the algorithm here, and is probably best suited to deciding.

• I agree that there's something not so clear about whether family = "Ubuntu Light" should match with weight = "Regular" (in that it's the "Regular" "Ubuntu Light" font). Maybe we need FontProperties attributes to have an "unset" value (differing from "Regular")? How does e.g. CSS matching (which is very well specified) work in that case?
• How does the name detection compare with fontconfig's algorithm (at https://cgit.freedesktop.org/fontconfig/tree/src/fcfreetype.c#n1384)?

Thanks for the questions! I reviewed fontconfig's FcFreeTypeQueryFaceInternal and the CSS font matching spec to understand this better.

Re: fontconfig comparison:

The approach is very similar - both iterate over name IDs (1/16/21 for family, 2/17/22 for subfamily) on Mac and Microsoft platforms, then parse the subfamily string for weight keywords.

The main difference: fontconfig uses -1 as "unset" and defaults to FC_WEIGHT_MEDIUM if no weight is found, while my code defaults to 400 immediately when no keyword matches.

Re: "unset" vs 400:

I chose 400 to match matplotlib's existing behavior and CSS semantics. In CSS, an unspecified weight always resolves to a numeric value (typically 400/"normal") before font matching begins. So when a user requests family='Ubuntu Light' without specifying weight, they get the "Regular" variant of that family.

However, I'm open to using a sentinel value (like None) if you think that better represents these alternate families. The tradeoff is it would require changes to the scoring function to handle unset weights.

Re: CSS matching:

CSS Fonts Level 4 spec defines normal = 400, and the matching algorithm searches outward from the requested weight when exact matches aren't available. There's no concept of "unset weight" in the matching algorithm - it always works with numeric values.

Let me know if you'd prefer a different approach for handling the weights.

Done, also fixed the face-loop conflict in addfont and the set append in the test while rebasing onto text-overhaul.

Merged over known test failures that are resolved by other PRs

Thanks @Cemonix! Congratulations on your first PR to Matplotlib 🎉 We hope to hear from you again.