You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Light font variants cannot be accessed by common name #4822
Ubuntu Light is shown with two family names: Ubuntu and Ubuntu Light. In XeTeX I can select the font directly by naming Ubuntu Light, but I cannot do the same in matplotlib:
Ubuntu Light is shown with two family names: Ubuntu and Ubuntu Light. In
XeTeX I can select the font directly by naming 'Ubuntu Light', but I cannot
do the same in matplotlib:
@WeatherGod Apparently not, according to testing I did with the commit. I'm not an expert in the code, so I'm just reporting my observations below and making educated guesses.
The patch you mentioned seems to be about font family aliasing. The font Ubuntu-L.ttf is only known to matplotlib as Ubuntu (this being, for example, the value of family2 in FontManager.score_family()), not Ubuntu Light, so the issue of aliasing doesn't apply here.
The two relevant parameters considered by the scoring algorithm in this case is family and weight. If I just say
the algorithm tries to find a font called Ubuntu Light at 400 weight. The font VeraSe.ttf has name Bitstream Vera Serif and weight 400, while the font Ubuntu-L.ttf has name Ubuntu and weight 200; as a result, and somewhat illogically, the algorithm finds a better match in the first font. But since the score is 10 because of a mismatch in family name, the algorithm gives up anyway and falls back to the default font, which is Bitstream Vera Sans.
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
I think this is fairly actionable and self-contained, so labeling as good first issue, although fixing this will require being able to read some C and learning about font metadata (I can't provide any help on that), thus medium difficulty. The fixes are
Port fontconfig's font family name extractor to python and make (a variant of) ttfFontProperty report all family names for a font, so that we can record each of them in the json fontlist.
Port fontconfig's stretch (weight) detector to python and use it similarly to what I did for the weights.
This issue is suited to new contributors because it does not require understanding of the
Matplotlib internals. To get started, please see our contributing
guide.
We do not assign issues. Check the Development section in the sidebar for linked pull
requests (PRs). If there are none, feel free to start working on it. If there is an open PR, please
collaborate on the work by reviewing it rather than duplicating it in a competing PR.
Activity
WeatherGod commentedon Jul 29, 2015
It might be that you need to clear your matplotlib font cache.
On Wed, Jul 29, 2015 at 4:05 PM, Edwin Chan [email protected]
wrote:
EdwinChan commentedon Jul 29, 2015
@WeatherGod That was the first thing I tried; before doing that, I couldn't even load the plain Ubuntu font.
WeatherGod commentedon Aug 7, 2015
I am wondering if this is addressed by #4689
On Wed, Jul 29, 2015 at 6:05 PM, Edwin Chan [email protected]
wrote:
EdwinChan commentedon Aug 14, 2015
@WeatherGod Apparently not, according to testing I did with the commit. I'm not an expert in the code, so I'm just reporting my observations below and making educated guesses.
The patch you mentioned seems to be about font family aliasing. The font
Ubuntu-L.ttfis only known to matplotlib as Ubuntu (this being, for example, the value offamily2inFontManager.score_family()), not Ubuntu Light, so the issue of aliasing doesn't apply here.The two relevant parameters considered by the scoring algorithm in this case is family and weight. If I just say
the algorithm tries to find a font called Ubuntu Light at 400 weight. The font
VeraSe.ttfhas name Bitstream Vera Serif and weight 400, while the fontUbuntu-L.ttfhas name Ubuntu and weight 200; as a result, and somewhat illogically, the algorithm finds a better match in the first font. But since the score is 10 because of a mismatch in family name, the algorithm gives up anyway and falls back to the default font, which is Bitstream Vera Sans.QuLogic commentedon May 15, 2017
Might be related to #8551 or #8587.
anntzer commentedon Jan 14, 2018
It is indeed similar to the font weight retrieval issue: a ttf file can have its name stored in a bunch of different places and we currently only check for one of them (https://cgit.freedesktop.org/fontconfig/tree/src/fcfreetype.c#n1368 for all places where fontconfig looks).
In the specific case of Ubuntu-L, "Ubuntu" is the TT_NAME_ID_FONT_FAMILY whereas "Ubuntu Light" is the TT_NAME_ID_TYPOGRAPHIC_FAMILY.
Fixing this will require either depending on fontconfig or extracting all the names ourselves, which is unlikely to happen before 2.2...
16 remaining items
github-actions commentedon May 1, 2024
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
liuzhenqi77 commentedon May 1, 2024
Guess still persists?
anntzer commentedon May 1, 2024
I think this is fairly actionable and self-contained, so labeling as good first issue, although fixing this will require being able to read some C and learning about font metadata (I can't provide any help on that), thus medium difficulty. The fixes are
github-actions commentedon May 1, 2024
Good first issue - notes for new contributors
This issue is suited to new contributors because it does not require understanding of the
Matplotlib internals. To get started, please see our contributing
guide.
We do not assign issues. Check the Development section in the sidebar for linked pull
requests (PRs). If there are none, feel free to start working on it. If there is an open PR, please
collaborate on the work by reviewing it rather than duplicating it in a competing PR.
If something is unclear, please reach out on any of our communication
channels.
QuLogic commentedon Apr 11, 2026
This was fixed by #31183.