-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Add font feature API to Text #29695
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?
Add font feature API to Text #29695
Conversation
A difficulty that I've not really handled with mplcairo but warrants at least discussion is what you want to do with subranges. Harfbuzz supports toggling a feature only for some of the characters (see https://harfbuzz.github.io/harfbuzz-hb-common.html#hb-feature-from-string, e.g. The two main alternatives I can think of are either to do nothing, like mplcairo (subranges are interpreted as "repeated over each line"), or to reparse ranges and reinterpret them as "indices over the full string" (after line splitting, matplotlib tweaks the actual ranges than get fed to harfbuzz when shaping each line). |
Also, looking at this again, I wonder how well this will interact with font fallback: it seems not unreasonable that two entries in the font fallback list would want to use different font features (e.g., a latin script and a chinese script likely want very different font features). Perhaps the real question here is whether font fallback should really have been implemented by stashing (references to) multiple fonts in a single FontProperties (though I'm not sure I can immediately design something much better), but the PR here makes the question more salient, I'd say. |
Since we have automatic wrapping ( For settings across font fallback, I guess that is possible to do, but it might require quite a bit of bookkeeping work. |
The comments at #29794 (comment) also apply, but because this PR doesn't actually touch the rendering API, I guess it's fine. |
Discussed on a developer call we decided to not implement the sub-range application yet. Promoting a tuple of strings to |
Even if we don't explicitly support sub-ranges, we still need to decide what happens if someone writes e.g. |
Since we moved the information from matplotlib/lib/matplotlib/text.py Line 805 in b4cb934
I tried a small change: diff --git a/lib/matplotlib/text.py b/lib/matplotlib/text.py
index 3b0de58814..b255a93c52 100644
--- a/lib/matplotlib/text.py
+++ b/lib/matplotlib/text.py
@@ -800,9 +800,7 @@ class Text(Artist):
angle = self.get_rotation()
for line, wh, x, y in info:
-
- mtext = self if len(info) == 1 else None
x = x + posx
y = y + posy
if renderer.flipy():
@@ -816,14 +814,19 @@ class Text(Artist):
else:
textrenderer = renderer
- if self.get_usetex():
- textrenderer.draw_tex(gc, x, y, clean_line,
- self._fontproperties, angle,
- mtext=mtext)
- else:
- textrenderer.draw_text(gc, x, y, clean_line,
- self._fontproperties, angle,
- ismath=ismath, mtext=mtext)
+ xt, yt = self.get_transform().inverted().transform((x, y))
+ with cbook._setattr_cm(self, _x=xt, _y=yt, _text=clean_line,
+ convert_xunits=lambda x: x,
+ convert_yunits=lambda y: y,
+ _horizontalalignment='left', _verticalalignment='bottom'):
+ if self.get_usetex():
+ textrenderer.draw_tex(gc, x, y, clean_line,
+ self._fontproperties, angle,
+ mtext=self)
+ else:
+ textrenderer.draw_text(gc, x, y, clean_line,
+ self._fontproperties, angle,
+ ismath=ismath, mtext=self)
gc.restore()
renderer.close_group('text') AFAICT, only the PGF backend uses matplotlib/lib/matplotlib/backends/backend_pgf.py Lines 697 to 700 in 6db18d5
|
Font features allow font designers to provide alternate glyphs or shaping within a single font. These features may be accessed via special tags corresponding to internal tables of glyphs. The mplcairo backend supports font features via an elaborate re-use of the font file path [1]. This commit adds the API to make this officially supported in the main user API. At this time, nothing in Matplotlib itself uses these settings, but they will have an effect with libraqm. [1] https://github.com/matplotlib/mplcairo/blob/v0.6.1/README.rst#font-formats-and-features
I've added a note about subranges in multiline text, some comments about where TODO items are left, and rebased on the Everything should now pass as well due to preloading from #30231. |
Looking at this in relation to #30282, I wonder (sorry for opening again a potential can of worms) whether associating the font features (and likewise the language) with the Text object is really the better design, or whether they should be associated with the FT2Font object; i.e., consider that the same font with different features is really two different font objects (possibly with some caching along the way) and support feature ranges by actually supporting having multiple fonts in the same text string. Then the fundamental rendering function would no longer be a FT2Font method, but a free function like |
That seems like a fairly large change, and I'm not sure how it would interact with the fact that you can essentially construct |
We discussed this idea on the call earlier today, though we did not have quorum to decide anything. @tacaswell suggested that we provide some lightweight description of ranged-properties to apply to all font properties keyword arguments that could be passed to However, as that is an additional large set of changes, we likely want to defer doing anything of the sort right now until after all the libraqm PRs are in. So the plan would be something like:
I'd also like to confirm with @timhoffm whether this seems alright from an API point of view, or if he can see some kind of clash between steps 1 and 3. Or if we'd want to expose this ranged-setting option in a different way to the user, or not at all. |
1 is ok. I have some reservations on 3. I believe Multiple formats are effectively a form of rich text. I'd rather either decide not to support that, or alternatively go one step further and consider some sort of mini-language, e.g. a subset of markdown or html as a text-based rich text standard. We'd have to write (or use as optional dependency) as parser. The parsed text structure would then be transformed to the chain of FTFont objects. |
Would this be akin to something like https://github.com/znstrider/highlight_text or https://github.com/tomicapretto/flexitext? |
Anything uncovered would use the default (rcParams, effectively.) I can't say about overlap, though I'd expect an error. I do agree that this is somewhat cumbersome, though.
I did consider that after the call, and I expect something HTML-like is most likely to be familiar with users. How difficult that would be to implement, I haven't determined.
These are good, though I think one downside is they need to layout themselves. Each different font block (including bold vs normal) is laid out separately and joined with For now though, I think we'll stick with 1 and not specifically try to do any ranged setting applications. |
That’s a reasonable first step and we can still go either way later. |
This would break interaction between parts of text that use different features, e.g. "AV" string and user wants to enable a feature on "V" glyph, if this results in two fonts then no kerning will be applied between the two glyphs. |
PR summary
Font features allow font designers to provide alternate glyphs or shaping within a single font. These features may be accessed via special tags corresponding to internal tables of glyphs.
The mplcairo backend supports font features via an elaborate re-use of the font file path. This commit adds the API to make this officially supported in the main user API.
At this time, nothing in Matplotlib itself uses these settings, but they will have an effect with libraqm. I am opening this PR early for review of the API while I work through some issues with the latter. Consequently, the What's New note will not show the effect of this API, and there are only smoke tests.
PR checklist