Pango development has been slow in the last few years, while most of the
work on the text
rendering stack has moved to harfbuzz. But recently, Behdad and I got
together for a pango
work day, and made some plans, which we want to share. The underlying goal
of these changes
is to ensure that GTK+ and GNOME continue to have a competitive text
rendering stack,
and to avoid pango becoming a roadblock for this.

To give some background, pango provides these major pieces of
functionaliity. Originally,
pango has had a backend- and module-based architecture to implement most of
these things per platform:

- Unicode text analysis (direction, scripts, languages).

This is mostly based on Unicode data tables which are for the most part
(but not entirely)
provided by GLib and firibidi.

- Font enumeration.

Font enumeration will remain platform-specific, with a Linux implementation
on fontconfig.

- Shaping.

Shaping is the domain of harfbuzz, and we want to use it on all platforms
in the
future. The web browsers are ahead of us here, and already use harfbuzz
platforms. The soon-to-be released harfbuzz 2.0 will close one of the last
few feature
gaps for this by supporting Apple-specific font tables.

- Font rendering.

For rendering, we nowadays rely on cairo everywhere.

In terms of concrete plans, we want to

- Move things that need to be updated with Unicode (scripts, character
  to GLib and/or fribidi

- Update the Emoji iterator to be in sync with chrome

- Use harfbuzz for shaping everywhere

- Provide api to make harfbuzz objects available, so we can get access to
  features without wrapping everything in pango api

There's also a small amount of feature work that we've looked at:

- Add some apis to support font variations

- Subpixel positioning

There is a gitlab milestone to track these:
gtk-devel-list mailing list

Reply via email to