bug#58184: Faulty font selection for Latin characters

[समीर सिंह Sameer Singh]

It's ok, at least I found the cause of my problem.

You can close the bug report.

Thanks

On Fri, Sep 30, 2022 at 6:22 PM Eli Zaretskii <eliz@gnu.org> wrote:

> From: समीर सिंह Sameer Singh <lumarzeli30@gmail.com>
> Date: Fri, 30 Sep 2022 18:05:02 +0530
> Cc: 58184@debbugs.gnu.org
>
> I think I may have found the problem here, JetBrains Mono does not have the glyphs for these
> "faulty" characters that is why Emacs chooses a different font for them, but the thing is these characters
> can still be displayed in the correct font i.e. JetBrains Mono by combining the glyphs which made up the
> unsupported glyph, this is why hb-view was able to display them I guess.
> For example entering ṃ (#x1e43 Latin small letter m with a dot below) will result in it being displayed in a
> different font,
> but entering ṃ (m + #x323 Combining dot below) will result in it being displayed with JetBrains Mono.
>
> So now the question is should these characters be decomposed to better fit with other characters when the
> font does not support them?

We cannot do that in the buffer text, because that would mean
modifying the text behind user's back.  And doing this in display code
woul mean activating character composition where none should happen.

I think fonts that don't have glyphs for precomposed characters
shouldn't be used in Emacs for text that could have the codepoints of
those characters.  Emacs doesn't pass every character to the shaping
engine, and so the tricks of decomposing characters to get them
displayed are something we cannot be expected to do.  Sorry.