GNU bug report logs - #58184
Faulty font selection for Latin characters

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: समीर सिंह Sameer Singh <lumarzeli30 <at> gmail.com>
Cc: 58184 <at> debbugs.gnu.org
Subject: bug#58184: Faulty font selection for Latin characters
Date: Fri, 30 Sep 2022 15:52:38 +0300

> From: समीर सिंह Sameer Singh <lumarzeli30 <at> gmail.com>
> Date: Fri, 30 Sep 2022 18:05:02 +0530
> Cc: 58184 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.