The What's New entrywith libraqm will look something more like this (minus a bug with the kerning, hopefully):

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 (seehttps://harfbuzz.github.io/harfbuzz-hb-common.html#hb-feature-from-string, e.g.aalt[3:5]=2), which mplcairo just forwards directly to harfbuzz, but this can(?) become problematic for multiline inputs, which get fed (by matplotlib) one-line-at-a-time to the rendering machinery, so something likeaalt[3:5] likely(?) gets interpreted as "characters 3-to-5of each line" rather than "characters 3-to-5 of the entire string".

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 (Text(..., wrap=True)), I think the only possible implementation is to reparse the ranges ourselves.

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 toDict[tuple[int, int], Tuple[str, ...]] is something we can do unambiguously later and given that we expect most strings to be "short", hopefully the demand for mixed language within oneText object will be low.

Even if we don't explicitly support sub-ranges, we still need to decide what happens if someone writes e.g.fontfeatures=["+kern[3:5]"] (where the whole syntax gets interpreted by harfbuzz). It's probably fine to just document the limitation for now ("the interaction of subranges and multiline text is currently unspecified and behavior may change in the future").

Since we moved the information fromFontProperties toText, I was actually going to implement the splitting.However, I ran into an issue in that theText object is only supplied toRenderer.draw_text if the string is not multiline:

diff --git a/lib/matplotlib/text.py b/lib/matplotlib/text.pyindex 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 usesmtext and under certain conditions will place the text using the original position and alignment instead of thex/y passed todraw_text. Unfortunately, these don't seem to match (I assume the x/y passed in accounts for the descenders and other flourishes), so this breaks the PGF tests. I wonder if there's a better condition to be put in here: