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 based 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 across 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 properties) 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 harfbuzz 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: https://gitlab.gnome.org/GNOME/pango/milestones/9
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
