GNU bug report logs - #54562
28.0.91; Emoji sequence not composed

Previous Next

Full log

Message #137 received at 54562 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: luangruo <at> yahoo.com, larsi <at> gnus.org, 54562 <at> debbugs.gnu.org
Subject: Re: bug#54562: 28.0.91; Emoji sequence not composed
Date: Tue, 29 Mar 2022 18:42:03 +0300

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: luangruo <at> yahoo.com,  larsi <at> gnus.org,  54562 <at> debbugs.gnu.org
> Date: Tue, 29 Mar 2022 16:50:10 +0200
> 
>     Eli> We could perhaps avoid the complexity by rewriting the composition
>     Eli> rule for diacritics.  Instead of "\\c.\\c^+" with 1-character
>     Eli> look-back, we could have several rules:
> 
>     Eli>    "\\c.\\c^\\c^\\c^\\c^" with 4-character look-back
>     Eli>    "\\c.\\c^\\c^\\c^+"    with 3-character look-back
>     Eli>    "\\c.\\c^\\c^+"        with 2-character look-back
>     Eli>    "\\c.\\c^+"            with 1-character look-back
> 
>     Eli> (in that order).  I didn't test this, but if it works, maybe it could
>     Eli> solve the problem without any deep changes on the C level.
> 
> That might work. What would the fallback look like? Suppose we have 4
> diacritics, 3 of which are covered by the same font, and one by a
> different one. Would you prefer to attempt to use the font of 3 of
> them, or would you prefer to fall back to the font of the base
> character?

I think I'd prefer to have the font that covers the majority.

But I'm not sure it's a real-life dilemma.  I fully expect a font that
supports the rare diacritic to also support the less rare ones.  And
if I'm wrong, I'm sure we will hear about that soon enough ;-)

Previous Next

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