Activity

1. thangleiter

   added

   New feature

   on Apr 3, 2025
2. oscargus

   added

   topic: text/fonts

   on Apr 6, 2025
3. socram-somel commented on May 9, 2025

   

   socram-somel

   on May 9, 2025

   More actions

   It seems like a good idea. My colleague @bruswaine and I would like to tackle this in the coming weeks—how does that sound?
   At first glance, it seems that benchmarks are not required, as this change doesn’t appear to have a performance-critical impact. What’s your take on this?
4. thangleiter commented on May 9, 2025

   

   thangleiter

   on May 9, 2025

   ContributorAuthor

   More actions

   Sounds good, thanks!
5. tacaswell commented on May 9, 2025

   

   tacaswell

   on May 9, 2025

   Member

   More actions

   While it is true that performance is not a major concern here, this is like a major changes to the API which is significantly more impactful!

   It is not clear to me that the proposed change is a standard naming convention as per https://fonts.google.com/knowledge/glossary/family_or_type_family_or_font_family the family is the typeface and the variants are weight and styles which is exactly how we are currently using it (with the extension borrowed from css of 5 "generic" names). Quoting the above link

   When there are serif and sans serif (or slab serif, or monospaced, etc.) versions of a typeface, they’re often collectively referred to as a superfamily.

   which is not a concept we currently express in any part of the API. This pushes me to reframe this as "how do we add super families to mpl" (https://fonts.google.com/knowledge/glossary/superfamily) then I think there is a path forward, but I think there are some significant API choices to be made.

   The first constraint is: no existing user code can break by default! If someone does not opt-into using super families then things that ran on old versions of Matplotlib should still run on new versions. This includes both default values of settings and the API of any of the font / font discovery code.

   If we are going to support a third meaning of font.family, what should we do in the case where the user sets font.superfamily='Roboto' and `font.family='DejaVu Serif'? We can not do both! I can think of three option (explode, use dejavu serif, use Roboto Serif) but on first pass do not see a reason to prefer any of them over the others.

   How is this going to get threaded through the font search API?

   How is this going to interact with the fontfallback API? Do we auto-pupulate with all of the members of the super family in some order? In the OP it suggested going with any sans font, but would it be better to go with any other member of the super family? Again, on first pass I don't see why one is clearly preferable to the other.

   Any work on this needs to be done aware of the changes coming from #30000 and the work around that.

   This may also need some API work done so that Matplotlib can access more than the first font in a given font file (I do not recall off the top of my head if #300000 or #29816 or the associated work is adding that yet).

   ---

   If you want to work on this the first step is to write out a plan that addresses the issues above (and I expect will identify a bunch more I did not think of!). The second would be to write a prototype helper class that given superfamily can manage getting the font objects we need to render, something like

   class FontSuperfamily:
       def __init__(self, name: str): ...
       # or if we want init to be something like a list of files + indexes
       @classmethod
       def get_superfamily(cls, name: str) -> Self: ...
       def get_family(self, genre: str, weight=None: int|str|None, style=None: str|None) -> Font: ...

   Once the prototype manager is fully featured and working, I think it will be clearer how to thread that back through the current code base (and how to document it!).
6. socram-somel

   added a commit that references this issue on Jun 6, 2025

   Add font.superfamily support with genre-aware resolution

   This issue will close once commit 74d6684 is merged into the 'main' branch.

   74d6684