Re: Display of decomposed characters

[Philipp <p.stephani2@gmail.com>]

> Am 19.03.2021 um 17:44 schrieb Eli Zaretskii <eliz@gnu.org>:
> 
>> From: Philipp <p.stephani2@gmail.com>
>> Date: Fri, 19 Mar 2021 17:37:31 +0100
>> Cc: help-gnu-emacs@gnu.org
>> 
>>>>>> What if Emacs ignored font lookup for combining characters and always picked the font of the previous base character?
>>>>> 
>>>>> What would that produce if the font of the previous character didn't
>>>>> have a glyph for the accent?  The accent will disappear, or maybe will
>>>>> be displayed as "tofu", right?  Does that sound like a good strategy?
>>>> 
>>>> Can't the shaping engine produce fake compositions in that case?
>>> 
>>> What do you mean by "fake compositions"? what would they entail, and
>>> which glyphs would they use?
>> 
>> 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.

> 
>> (At least that would be a possibility; I don't know whether Harfbuzz actually does that.)
>> That would still produce suboptimal results, but probably slightly better ones.
> 
> I don't understand what you are describing here.  If the font does
> have U+00A8, what you describe already happens.  If the font doesn't
> have the glyph, what can the shaper do?

See above, here I'm assuming that U+0308 is unavailable not U+0048.

> 
> 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.

> 
>> 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.

> 
>> 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.