-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
[with findfont diff] Parsing all families in font_manager #20496
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
EDIT: This is solved now The tests now fail only due to an unrelated issue, and seems to be affecting all recent PRs. FAILED lib/matplotlib/tests/test_image.py::test_huge_range_log[png] - ValueError: Invalid vmin or vmax |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
findfont
is public API, so can we just change its return type? At the very least this requires an API change note?
@@ -20,10 +20,10 @@ | |||
def get_font_properties(): | |||
# The original font is Calibri, if that is not installed, we fall back | |||
# to Carlito, which is metrically equivalent. | |||
if 'Calibri' in matplotlib.font_manager.findfont('Calibri:bold'): | |||
if 'Calibri' in matplotlib.font_manager.findfont('Calibri:bold').keys(): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think you need .keys()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah that's right, I was probably searching for findfont usages within mpl and happen to change this eagerly.
Because this is a public API, the return type change is quite huge, which would break things at a lot of places. (including users who don't want their less-relevant part of their work getting messed up, which is also a bit hard to traceback) I've proposed a 'without findfont diff' parsing of all families, which would only change internals of mpl and won't affect end users. see: #20549 I think this PR should still be open for a while until we've got a good look at the other PR's possibilities. |
Please reference other relevant PRs in a PR before asking folks to review. I had no idea there were two, and we probably should decide on an approach before reviewing. |
I did? I see a On the other hand, the logic still needs to be reviewed (which is mostly similar in this and the other PR), which is also why I didn't convert it into a draft before.. |
Folks aren't going to click through every link on a PR. A quick comment here that this was likely superseded by the other PR would have been helpful. |
I am going to close this PR because the core of it got merged in #20740 and we have decided to keep the API on |
PR Summary
This is the beginning of migrating from Matplotlib's "Font-First" approach to a "Text-First" approach.
The very first step is to parse all families in font manager. Previously, we only parsed families until we find a font file, and the rest of the backends are accustomed to just a single font file (which needs changing)
I'm hoping this breaks many tests, so as to know exactly what to fix at other places.
findfont
, from simple 'str' to 'OrderedDict'font.family
I've added a bunch of To-Dos (future PRs) and some fixes at some places.
PR Checklist
pytest
passes).flake8
on changed files to check).flake8-docstrings
and runflake8 --docstring-convention=all
).doc/users/next_whats_new/
(follow instructions in README.rst there).doc/api/next_api_changes/
(follow instructions in README.rst there).