Fix that font files never pass the test on Win #24641
Conversation
There was a problem hiding this comment.
Thank you for opening your first PR into Matplotlib!
If you have not heard from us in a while, please feel free to ping @matplotlib/developers or anyone who has commented on the PR. 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
We strive to be a welcoming and open project. Please follow our Code of Conduct.
|
What about my comment about testing for the extension? The code path in the |
|
I think that @anntzer may know more about it. |
|
I suspect that the fix here is indeed incorrect as it will return files with incorrect extensions. The previous (wrong) code came in in #22909 to fix #22859, but given the discussion at #22859 I suspect that the correct approach on Windows is indeed to only return fonts listed by _get_win32_installed_fonts and not bother calling list_fonts at all. (Can anyone open a new issue with that, if they agree with my analysis?) |
|
Thanks for the historic background!
In the top post I stated my confusion for having two approaches that obtain (nearly) the same list of fonts. I think it would be good to pick one approach: either ask the registry, or scrape dirs with Indeed the discussion in #22859 seemed to be mostly about "what fonts are officially listed" (and show up in e.g. Word). I agree that this points towards asking the registry for a list (no Sidenote: in PyGfx I now took the approach to always scrape directories, because that way we can easily test when fonts are added/removed by checking a dir's mtime. |
Hi! 👋
I am gratefully making use of MPL's font management code for our text rendering in PyGfx. While I was examining the code, I found what I think is a bug.
The
isfile()test is applied on the relative pathname and will thus always fail. This PR should fix that. I would expect that it should also test for the extension, but I'm not 100% sure so I did not add this yet.Diving a bit deeper, this bug has likely gone unnoticed because the code to detect fonts follows two paths on Windows:
os.listdiroros.walk.Why are these two paths followed? I can see how the second route can find fonts that are present but not known in the registry, but why check the registry at all then?