Ingo Schwarze writes: > Hi, > > Anthony J. Bentley wrote on Fri, Dec 01, 2017 at 08:18:59AM -0700: > > Philippe Meunier writes: > > >> - In addition, when the precompose resource is set to false and TrueType > >> fonts are used, the result of printf "e\xcc\x81\n" itself is wrong (even > >> before trying to copy-paste it): od(1) shows that the correct sequence o > f > >> bytes is printed but it is displayed without accent. That's another bug > >> in xterm. The result is displayed correctly when the precompose resourc > e > >> is set to true. > > > Yes, this matches what I'm seeing. > > To me, that seems to imply that xterm(1), with the bugs it has now, > works significantly better with Precompose enabled: at least it > displays the correct glyphs, while there seem to be cases where it > displays wrong glyphs without Precompose. Right? > > Doesn't that imply that it would be better to fix this bug first, > before disabling Precompose? I certainly hate that xterm(1) is > doing normalization by default now, but if removing that exposes a > bug that causes display of incorrect glyphs, that would seem like > a serious regression to me. > > What do you think?
I was internally debating this earlier. The bug is already exposed by any combining characters that don't have precomposed forms. It also doesn't show up with the default (i.e. non TrueType) fonts. Given that and how unfriendly the precomposition behavior is, I think disabling it is still reasonable.
