Re: Display of decomposed characters

[Philipp]

> Am 24.01.2021 um 20:48 schrieb Eli Zaretskii <eliz@gnu.org>:
> 
>> From: Philipp Stephani <p.stephani2@gmail.com>
>> Date: Sun, 24 Jan 2021 19:58:18 +0100
>> Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
>> 
>>> If the default font supports the diaeresis, that will happen
>>> automatically.  If not, then simply don't choose the default font that
>>> doesn't support accents.
>> 
>> The font will always support the composite variant (because it's part
>> of Latin-1).
> 
> That is only relevant if Emacs decides to compose the characters.
> Then, and only then, will it ask the text-shaping engine to produce
> glyphs for the base character and the accent together, and then the
> font could provide a single precomposed glyph for them.

So in this case the decision to not compose the characters is incorrect or 
happens too early?

> 
>> I guess fonts assume that applications will first try to normalize
>> strings to avoid issues like this?
> 
> Normalizing strings before you know whether the font has the
> precomposed glyphs makes no sense.

Why? If the font doesn’t support a precomposed character, wouldn’t the 
rendering engine automatically fall back to a decomposed representation? 
(Serious question; I don’t know whether Harfbuzz does that.) IOW, would 
normalizing strings to NFC before sending them to the rendering engine ever 
break anything?

> 
> What the text-shaping folks tell us is that we should pass _all_ the
> text through the text shaper, then the shaper will DTRT in every
> case.  But this would mean a thorough redesign and reimplementation of
> how we do that in Emacs, and that is not easy if we want to keep the
> current flexibility and customizability (which is why the character
> composition code calls out to Lisp, and that makes sending all the
> text that way tool expensive to be practical).

Would it be possible to implement a more minimal change to fix the problem at 
hand?

> 
>> Does it ever make sense to pick different fonts for a base character
>> and its combining characters?
> 
> If the default font doesn't support the combining accent, what else
> can you do?  Most fonts don't have precomposed glyphs for every
> arbitrary sequence of base character followed by several combining
> accents.  So sometimes you will have to compose the accents "by hand",
> and that is not really possible if they come from different fonts.

Which is why they shouldn’t come from different fonts. What if Emacs ignored 
font lookup for combining characters and always picked the font of the previous 
base character?

> 
>> Wouldn't that fundamentally prevent using combining characters? IIUC
>> text rendering engines should be able to pick the right glyph if
>> that didn't happen (assuming they can perform Unicode
>> normalization).
> 
> Unicode normalization is only tangentially relevant here.
> 

Sure, but in this case it would fix them problem AFICS.