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
Received on Wed Sep 26 2018 - 14:37:19 CEST