Here is another update on what will appear in Pango 1.50 soon. Quite a few things, as it turns out. (This is a continuation of my last Pango update)
Bidi Improvements
Pango has long claimed to have good support for bidirectional text rendering and editing. But until recently, there were some annoying bugs: you could end up in loops when moving the cursor through mixed-direction text.
The relevant code has been rewritten, closing a very old bug (#157).
Useful Information
Modern fonts can contain a lot of different information – there can be colormaps, and glyphs can be represented not just as splines, but also as pngs or svgs.
For GTK, an important piece of information for each glyph is whether it is colored or monochrome. With the new PangoGlyphVisAttr.is_color
field, GTK no longer needs to poke directly at the font data to find out.
Another case where GTK needed data that wasn’t available through Pango APIs has been closed with pango_font_get_languages(). This data is used in the font chooser filter popup:
Superscripts and subscripts
Superscripts and subscripts now use font metrics information for size changes and baseline shift. They can also be properly nested, so markup like
2<sup>2<sup>2</sup></sup>
yields the expected rendering:
Customizing segmentation
Pango determines word and sentence boundaries according to the Unicode Text Segmentation Spec (TR29). The specification can’t deal with all the complexities of formatted text, so sometimes its results need tailoring, which can now be done with the new word and sentence attributes:
$ pango-segmentation --kind=word --text=\ "<span segment='word'>1-based</span> index" |1-based| |index|
Better Markup
Besides the new attributes that have been mentioned, Pango markup now lets you specify many attributes in more natural units.
For example, you can now say
<span font_size='12.5pt'>
instead of
<span font_size='12800'>
Small Caps
Pango has had the PangoVariant enumeration with its PANGO_VARIANT_SMALL_CAPS value since forever, but it has never done anything. Since we’ve added support for OpenType features (in Pango 1.37), it has been possible to produce Small Caps by using the smcp=1
feature, if the font supports it. Sadly, most fonts don’t.
With the text transformation and font scaling infrastructure now in place, it was easy to emulate Small Caps for fonts that don’t support this natively:
While at it, we’ve expanded the PangoVariant enumeration to cover all the CSS casing variants, and made the GTK CSS engine use them instead of OpenType features.
Better debugging
Pango ships with a versatile test utility called pango-view, which has options to test many of Pangos layout features. It has recently learned to show more auxiliary information in visual form, like glyph extents, caret positions and slopes:
$ pango-view --text Boxes \ --annotate=glyph,caret,slope
Enjoy!
So, how zany could Pango get in the process of synthesizing faux small caps? For variable fonts, there could be some interesting tricks to employ for matching weight (etc), but it could become a bit of a rabbit hole….
In https://gitlab.gnome.org/GNOME/pango/-/issues/621 Behdad figured out how to make fontconfig apply opsz to improve our scaling. Thats about as zany as we got so far…