Hi again, I did refresh my knowledge on unicode/font stuff, and yes, st will be screwed:
An unicode string has 4 canonical normalizations. But only one (NFD) seems to be futur proof regarding what features will be supported by font files (opentype(microsoft tm)/open font format). Ofc, this is the one canonical normalizations which hard depends on harfbuzz shaping in freetype. For instance the glyph 'é' won't be anymore 1 glyph (a "pre-combined" glyph) in the font file but will be the combined rendering of 'e' + 'combining accent' glyphs which only harbuzz understands and not freetype alone. Font designers are pushed to avoid making "pre-combined" glyphs: pre-combined glyphs are not allowed in unicode anymore (actually, it has been the case for quite some time). And that's the simple case of combined glyphs... Additionally, xml smile/svg vector rendering was introduced in the otf/ttf font format with animated color emojis: A futur "clean" pure xml font format is lurking on the horizon (open type 2?). The unicode canonical normalization also affects input: the application won't receive anymore 1 unicode code point for a "pre-combined" symbol 'é', but 2 unicode code points 'e' + 'combining accent'. st is surrounded. The suckless futur proof solution: it is over, st goes 7bits ascii only with it's own bitmap fonts... non english-only terminal users will just trash it. ... or a suckless futur proof unicode/font stack will have to be coded: - unicode normalizer (NFD) (like ICU) - a full xml smile/svg vector renderer (like librsvg/expat for the svg part) - a ttf/otf -> xml svg translator (in freetype). ... or st becomes like surf: an app which is a thin suckless wrapper around a huge pile of ... You know what: st would be better of being a thin wrapper around libvte then, because it would be even thiner. :( -- Sylvain