Re: Display of decomposed characters

[Eli Zaretskii]

> From: Philipp <p.stephani2@gmail.com>
> Date: Sun, 21 Mar 2021 12:43:47 +0100
> Cc: help-gnu-emacs@gnu.org
> 
> >> For example, the shaping engine could use U+00A8 (assuming it's available 
> >> in the font), but place it on top of the base glyph, without horizontal 
> >> shift.
> > 
> > First, we were talking about the case where U+00A8 is NOT available in
> > the font.  (If it _is_ available, then this whole discussion is
> > pointless, because things already work well in that case.)
> 
> No, the case is that U+00A8 (the spacing diaeresis) is available, but U+0308 
> (the combining diaeresis) is not.

But that's a completely different character, with a completely
different metrics.  The results of superimposing them may well be
illegible.  It is certainly not what the author of the text intended.

And then what to do about diacritics which don't have such
counterparts?

> > The horizontal shift happens because we use U+00A8 from a different
> > font.  Placing a glyph from a different font on top of a base glyph is
> > in general an impossible task, because different fonts have different
> > ways of describing the points where the accents shall be placed on top
> > of base characters.
> 
> Yes, but a fallback option where the two glyphs would just be centered 
> horizontally on top of each other would be at least thinkable.  It wouldn't 
> give great results, but I wouldn't call it impossible.

It could be illegible.  The two dots could become located on some part
of the base character, for example.  Think lower-case and upper-case
base characters.

> >> The optimal approach (for this case) would still be to try out composition 
> >> before font selection, and use that if it works.
> > 
> > I tried to explain why that's not possible, but I guess I failed
> > miserably.
> 
> At least I'm not convinced.  Surely it's possible to call 
> ucs-normalize-NFC-string before selecting fonts or sending a combined 
> character sequence to the shaping engine, it produces optimal results in this 
> case (I've tried it), and 
> https://lists.freedesktop.org/archives/harfbuzz/2011-July/001426.html appears 
> to talk about something very similar.  The question is rather whether this 
> normalization would cause more problems than it fixes; at least the Harfbuzz 
> approach shouldn't.

Once again: (a) HarfBuzz folks (which are better text-shaping expert
than me and you combined) tell us this is the job of the shaping
engine, in particular because the shaper can handle the codepoints in
any order, not just the canonical order; (b) what about sequences
where NFC produces nothing (because the precomposed character doesn't
exist)?

> >> I should note that Emacs is not alone in producing suboptimal results in 
> >> this case; other GUI programs on that systems appear to either perform the 
> >> fake composition I mentioned before, or no composition at all (placing the 
> >> base and combining characters next to each other).
> > 
> > Which should tell us something about the issue and the ways it can and
> > cannot be solved.
> 
> It tells us that it's a difficult problem, as text rendering is in general.  
> But it's not unsolvable: for example, I just tried Firefox and Google Chrome, 
> and both produce optimal results.

But that doesn't mean they do what you propose we should do.