[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#54562: 28.0.91; Emoji sequence not composed
From: |
Eli Zaretskii |
Subject: |
bug#54562: 28.0.91; Emoji sequence not composed |
Date: |
Tue, 29 Mar 2022 18:42:03 +0300 |
> From: Robert Pluim <rpluim@gmail.com>
> Cc: luangruo@yahoo.com, larsi@gnus.org, 54562@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 ;-)
- bug#54562: 28.0.91; Emoji sequence not composed, (continued)
- bug#54562: 28.0.91; Emoji sequence not composed, Po Lu, 2022/03/27
- bug#54562: 28.0.91; Emoji sequence not composed, Robert Pluim, 2022/03/28
- bug#54562: 28.0.91; Emoji sequence not composed, Eli Zaretskii, 2022/03/28
- bug#54562: 28.0.91; Emoji sequence not composed, Robert Pluim, 2022/03/28
- bug#54562: 28.0.91; Emoji sequence not composed, Eli Zaretskii, 2022/03/28
- bug#54562: 28.0.91; Emoji sequence not composed, Robert Pluim, 2022/03/28
- bug#54562: 28.0.91; Emoji sequence not composed, Eli Zaretskii, 2022/03/28
- bug#54562: 28.0.91; Emoji sequence not composed, Robert Pluim, 2022/03/29
- bug#54562: 28.0.91; Emoji sequence not composed, Eli Zaretskii, 2022/03/29
- bug#54562: 28.0.91; Emoji sequence not composed, Robert Pluim, 2022/03/29
- bug#54562: 28.0.91; Emoji sequence not composed,
Eli Zaretskii <=
- bug#54562: 28.0.91; Emoji sequence not composed, Robert Pluim, 2022/03/29
- bug#54562: 28.0.91; Emoji sequence not composed, Eli Zaretskii, 2022/03/29
- bug#54562: 28.0.91; Emoji sequence not composed, Andreas Schwab, 2022/03/28
- bug#54562: 28.0.91; Emoji sequence not composed, Robert Pluim, 2022/03/28
- bug#54562: 28.0.91; Emoji sequence not composed, Andreas Schwab, 2022/03/28
- bug#54562: 28.0.91; Emoji sequence not composed, Eli Zaretskii, 2022/03/28
- bug#54562: 28.0.91; Emoji sequence not composed, Andreas Schwab, 2022/03/28
- bug#54562: 28.0.91; Emoji sequence not composed, Robert Pluim, 2022/03/28
- bug#54562: 28.0.91; Emoji sequence not composed, Andreas Schwab, 2022/03/28
- bug#54562: 28.0.91; Emoji sequence not composed, Eli Zaretskii, 2022/03/28