FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

[Bug]: svg backend does not use configured generic family lists · Issue #23492 · matplotlib/matplotlib · GitHub

Repository navigation

[Bug]: svg backend does not use configured generic family lists #23492

Closed

Description

Bug summary

The FontProperties family parameter can be a generic family such as sans-serif and the actual font should be looked up in rcParams according to the documentation.

Code for reproduction

>>> import matplotlib as mpl
>>> import matplotlib.font_manager as fm
>>> mpl.rcParams["font.family"]
['sans-serif']
>>> mpl.rcParams["font.sans-serif"]
['DejaVu Sans',
 'Bitstream Vera Sans',
 'Computer Modern Sans Serif',
 'Lucida Grande',
 'Verdana',
 'Geneva',
 'Lucid',
 'Arial',
 'Helvetica',
 'Avant Garde',
 'sans-serif']
>>> fp = fm.FontProperties()
<matplotlib.font_manager.FontProperties at ...>
>>> fp.get_family()
['sans-serif']

Actual outcome

>>> fp.get_family()
['sans-serif']

Expected outcome

>>> fp.get_family()
['DejaVu Sans',
 'Bitstream Vera Sans',
 'Computer Modern Sans Serif',
 'Lucida Grande',
 'Verdana',
 'Geneva',
 'Lucid',
 'Arial',
 'Helvetica',
 'Avant Garde',
 'sans-serif']

Additional information

No response

Operating system

Windows

Matplotlib Version

3.5.2

Matplotlib Backend

TkAgg

Python version

3.9.13

Jupyter version

N/A

Installation

pip

Activity

  1. jklymak commented on Jul 26, 2022

    Member

    On the face of it, the result looks correct to me, so it seems the documentation is out of date? https://matplotlib.org/stable/api/font_manager_api.html#matplotlib.font_manager.FontProperties.get_family

  2. l-johnston commented on Jul 26, 2022

    ContributorAuthor

    Why is the result correct? Where, other than the documentation is the public API specified? If it's just documentation that is out of date, then the FontProperties docstring needs updating also.

  3. jklymak commented on Jul 26, 2022

    Member

    If you ask for the font_family, it seems reasonable to return the font_family?

  4. l-johnston commented on Jul 26, 2022

    ContributorAuthor

    but according to the docstring, get_family():
    Return a list of font names that comprise the font family.

    meaning get all the family members, as opposed to simply the family name.

  5. story645 commented on Jul 26, 2022

    Member

    meaning get all the family members, as opposed to simply the family name

    this seems more useful - do you have a guess of how hard it'd be to implement?

  6. jklymak commented on Jul 26, 2022

    Member

    Yes, I appreciate what the docs say. However, our usual pattern for setter/getters is for them to be reversible, so it would be unusual for get_family to return something other than what set_family was given.

  7. jklymak commented on Jul 26, 2022

    Member

    If this ever behaved differently, it was more than 8 years ago according to git blame. I'll stand by my assertion that this is a documentation error.

  8. l-johnston commented on Jul 26, 2022

    ContributorAuthor

    For a documentation error, this is massive wide scale errors where all the errors are consistent. set_family accepts a list of real fonts.

  9. story645 commented on Jul 26, 2022

    Member

    set_family() accepts a list of real fonts

    that sounds like this is a bug in Matplotlib where the intended behavior is what's stated in the docs and somehow didn't get implemented or got reverted years ago. thanks for catching that

    eta: I think this might be a consistency issue attn: @timhoffm

  10. l-johnston commented on Jul 27, 2022

    ContributorAuthor

    workaround is to set rcParams["font.family"] = 'list of real fonts'

  11. tacaswell commented on Jul 30, 2022

    Member

    To start with, I want to note that fonts are confusing. I do not think there are any major bugs or documentation errors here, however the documentation is ambiguous and should be clearer.


    First FontProperties are not actually fonts, they are the input to

    def findfont(self, prop, fontext='ttf', directory=None,
    fallback_to_default=True, rebuild_if_missing=True):
    (which is a wrapper around _findfont_cached defined right below) that takes in the props and gives back the file path of the closest font to the one requested. Internally we will eventually open what ever file that is and use it to render the text.

    Because the "family" on the FontProperties is a list (rather than a single name) this means you can list several fonts in preference order and we will use the first one that is actually installed. This behavior dates back to 2007-2008 and is consistent with css https://developer.mozilla.org/en-US/docs/Web/CSS/font-family . The ambiguity of using "family" to refer to the list, the things in the list, and the generic things seems to be an ambiguity that we inherited. I think the docstring on get_family should be clearer on which "family" it is referring too.

    The other question is when do we resolve the generic font families ("sans", "serif", ...). @l-johnston has the expectation that we resolve it eagerly when the family is set on the FontProperties, however we actually do it lazily when we are actually looking the font up at

    if family1 in font_family_aliases:
    options = [*map(str.lower, self._expand_aliases(family1))]
    . I think either behavior is defendable, however we have been doing it late from 2008.

    On net, I think doing it late is a preferable. If the rcparam for the generic families changes between when the FontProperties object is created and when the Figure is saved it is ambiguous which state should be used. "do what it says at draw time" seems easier to understand as if we resolved it early you could have N FontProperties than were created identically (but would at least not be equal) that all render differently!

    If we did go to eager evaluation, I would not expect the generic family to survive in the list.


    We do some light normalization in set_family to ensure that we always get a list back from get_family which wile it does not round trip, I think is reasonable behavior.

  12. added this to the v3.6.0 milestone on Jul 30, 2022
  13. 14 remaining items

  14. added a commit that references this issue on Aug 17, 2022
    1d42a5d
  15. modified the milestones: v3.6.0, v3.7.0 on Aug 24, 2022
  16. added 2 commits that reference this issue on Sep 1, 2022
    a48f1a2
    5027f6c
  17. added 4 commits that reference this issue on Sep 29, 2022
    3296b47
    ea34677
    a1cd412
    a0fcf79
  18. modified the milestones: v3.7.0, v3.6.1 on Oct 1, 2022
  19. added a commit that references this issue on Oct 18, 2022
    cdbf339
  20. added a commit that references this issue on Dec 19, 2022
    b5e7582
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions


      Back | FazBrowse Home | New Git URL