On Wed, Sep 26, 2018 at 10:01:48AM +0200, Laslo Hunhold wrote: > The vast majority of fonts uses the "native" OTF/TTF format anyway and > will in the future, because anything else would be a waste of resources > both on the font-developer-side and the rendering-part.
This is where I am not that confident looking at how things are going. I guess the right thing would be to start a vector renderer (a lean cairo without freetype), which understands the otf/ttf vector tables (not the too old ones)/NFD unicode in a step by step process, starting with the "easy" combined glyph rendering step (it would cover many common glyphs already). This renderer would not include the tons of quirk fixes freetype does include, but fonts are not hardware, they can be fixed quickly and redistributed (no need to be microsoft bug compatible) If microsoft decides to do the same thing with otf that what they did for .doc->.docx (xml-ization), only the front-end would have to be adapted, but the vector "hard" work would have be mostly done. That does not solve the issue of unicode NFD input though. Terminal line discipline is basically disabled since the line editing is done on application side (with readline or libedit). I guess xkb can emit a transactional series of unicode code points, then the xserver and wayland (xkb with libinput) should be fine. But how readline or libedit can be told that a "char" is actually several unicode code points? This is true while echo-ing back that "char" to the rendering part on the line too. Really, I hope unicode does include some "transactional mark unicode points". Would have been fun to deal with that, but I am currently in that c++ brain diareha which is llvm. Oh! I forgot, a little thing on the side, librsvg is being rewritten in... rust (The rust bootstrap SDK is a joke, have a look at it) xD -- Sylvain
