Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[without findfont diff] Parsing all families in font_manager #20549

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

Closed
wants to merge 8 commits into from

Conversation

aitikgupta
Copy link
Contributor

PR Summary

Short Note:

This is a newer and more dynamic approach than #20496, which changed findfont's API, thus breaking a lot of backends.
A much more flexible approach would be to gradually move the different backends to find_fontsprop instead of findfont, since the new function is built over the existing API and acts as a middleware.

Quoting previous PR:

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)


OrderedDict would contain fonts defined by font.family

  • which are present on the system
  • but also append "fallback fonts" in the end. (which is triggered if a certain font family is not found in the system)## PR Checklist

  • Has pytest style unit tests (and pytest passes).
  • Is Flake 8 compliant (run flake8 on changed files to check).
  • New features are documented, with examples if plot related.
  • Documentation is sphinx and numpydoc compliant (the docs should build without error).
  • Conforms to Matplotlib style conventions (install flake8-docstrings and run flake8 --docstring-convention=all).
  • New features have an entry in doc/users/next_whats_new/ (follow instructions in README.rst there).
  • API changes documented in doc/api/next_api_changes/ (follow instructions in README.rst there).

@jklymak jklymak marked this pull request as draft July 4, 2021 21:46
@jkseppan
Copy link
Member

jkseppan commented Jul 11, 2021

I added some inline comments, but my main request would be to add just a little high-level documentation on the proposed design (I talked about this on the call some time ago). How would this change how a user can control fonts? Say, I want to add text that includes both English and Russian, and I want to use two separate fonts. How would I specify the fonts? Or, my last name Seppänen includes a glyph that is not available in all fonts, and perhaps I prefer to have it taken from another font rather than see an empty space(*). Can I do this with the proposed design, and how?

Of course the full implementation is not there yet so any code samples would be somewhat hypothetical. But having them would increase the confidence that this is solving the right problems, and perhaps guide the implementation so that they would eventually become test cases.

Footnote (*): in reality it looks terrible to have the ä glyph come from another font where it does not match the a of the main font, so I would want to change the font for the whole text. But showing some version of the glyph is still preferable to showing nothing.

@aitikgupta
Copy link
Contributor Author

^^ Drop in the whole workflow/idea behind the per-glyph font fallback (not a lot of details, but on a user's perspective)

@aitikgupta
Copy link
Contributor Author

aitikgupta commented Jul 18, 2021

Things yet to complete:

  1. Add that high-level user-perspective documentation. edit: added this.
  2. Currently I've only used this API for Agg backend, need to figure out if we can simply reuse the function in other backends
  3. Also need to figure out how to stop spitting of the same warning multiple times. edit: fixed this too!

Apart from these, this PR could still use a re-review (because a major chunk of changes requested were based on FontsInterface, which I removed altogether)

@tacaswell tacaswell added this to the v3.5.0 milestone Jul 20, 2021

How does Matplotlib achieve this?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Well, Matplotlib doesn't achieve this, *yet*. It was initially only designed to
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We aim for the writing in the docs to be more formal.

[We also discussed this on the phone]

@@ -1308,6 +1309,100 @@ def findfont(self, prop, fontext='ttf', directory=None,
prop, fontext, directory, fallback_to_default, rebuild_if_missing,
rc_params)

def find_fontsprop(self, prop, fontext='ttf', directory=None,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We talked on the phone about renaming this. The should invoke that is is going at a) find multiple fonts b) that the order of the returned fonts matters.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some suggestions:

  1. find_fonts
  2. find_orderedfonts
  3. find_fontsdict
  4. find_fontorder
  5. find_fontset
  6. find_fontfamilies
  7. find_orderedfamily
  8. find_familyordered
  9. find_families
  10. find_fontfamilies

@QuLogic QuLogic modified the milestones: v3.5.0, v3.6.0 Aug 23, 2021
@QuLogic QuLogic removed this from the v3.6.0 milestone Jul 5, 2022
@QuLogic QuLogic added this to the v3.7.0 milestone Jul 5, 2022
@tacaswell
Copy link
Member

I am going to try rebasing this so that we capture the docs. I think the code changes were made redundent by #20740 .

@tacaswell
Copy link
Member

Closing in favor of #23621 which is this PR rebased, with the code changes dropped and the documentation extended.

@tacaswell tacaswell closed this Aug 15, 2022
@tacaswell tacaswell modified the milestones: v3.7.0, unassigned Aug 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants