-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Add support for loading all fonts from collections #30334
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
base: text-overhaul
Are you sure you want to change the base?
Conversation
We had a discussion about this on the call earlier.
We'll drop the tuple for now, as it seems the
We'll not deprecate anything for now, and see how this works out. Since
Will leave this for later, if necessary. |
Since we pass the filename to `io.open`, we can accept everything it can. Also, fix the return value of `FT2Font.fname`, which could be `bytes` if that was initially provided.
This enables loading a non-initial font from collections (`.ttc` files). Currently exposed for `FT2Font`, only.
This should allow listing the metadata from the whole collection, which will also pick the right one if specified, though it will not load the specific index yet.
For backwards-compatibility, the path+index is passed around in a lightweight subclass of `str`.
This should work almost everywhere now, I think. The only thing that doesn't support the face index is LaTeX, via PGF or |
Also, tests use the |
Note, this only has an effect if set as the global font. Otherwise, just the font name is recorded, and the TeX engine's normal lookup is performed.
PR summary
This turned out to be more straightforward than I expected, but it will probably need a few API decisions to be fully complete.
From bottom to top of the API:
FT2Font
accepts aface_index
parameter to specify which face to load in a collection, and a correspondingface_index
property to check what's loaded.FontManager.findfont
returns astr
-like classFontPath
(name up for debate) which has aface_index
attribute and is accepted byget_font
. If anyone uses them as strings though, it should act pretty much the same.For example, now I can see all variants of Noto Sans CJK:
or all variants of WenQuanYi that we use for tests:
Fixes #3135
TODO
API questions
str | bytes | Path
, I wonder if we should change toos.PathLike
?FontPath
, I'm thinking maybe that's redundant and we should just stick with theFontPath
class only. Do we want to accept the tuple form as well, or should I drop it?FontPath
is a subclass ofstr
which allows using it as astr
as one normally would. That was the minimum implementation needed, but we probably want to flesh that out a bit. At minimum, I think we should implement__eq__
and__hash__
so that you can use it as a dictionary key without clashing with an equivalentstr
. But then do we want to add a deprecation warning when making those comparisons? And after thinking about it a bit more, would anamedtuple
with__eq__
instead be a better choice?PR checklist