Re: Display of decomposed characters

[Philipp]

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