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
Received on Tue Sep 25 2018 - 23:25:12 CEST