[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: |
Mon, 28 Mar 2022 16:12:06 +0300 |
> From: Robert Pluim <rpluim@gmail.com>
> Cc: luangruo@yahoo.com, larsi@gnus.org, 54562@debbugs.gnu.org
> Date: Mon, 28 Mar 2022 14:46:09 +0200
>
> Eli> I guess we should try. It should be optional behavior, because Emacs
> Eli> never did that, and I cannot predict what will that do to all the
> Eli> different use cases where we compose text, and thus whether users
> will
> Eli> like that in all the cases. It could, for example, mean that a
> Eli> particular Latin character with a diacritic will be displayed with a
> Eli> font that's different from the rest of the Latin text, which some
> Eli> users might consider worse than seeing just the base character in the
> Eli> "expected" font. And that's just the simplest use case.
>
> Yes, thatʼs exactly what happens with U+0308 here sometimes, see
> screenshot below. I had to search a bit to find a font to use as the
> default that didnʼt have a glyph for U+0308, so Iʼm not sure how
> important this issue is in practice.
I wasn't talking specifically about U+0308, I was talking about
combining diacritics in general. Some newer ones could be missing
from fonts that otherwise cover Latin character sets.
> Eli> "Look at" in what sense?
>
> 'consider'
>
> Rough patch attached. It does U+20E3, U+0308, and U+20D0..U+20FF. It
> works kind of ok, but U+006F U+0308 suffers from the font problem you
> were worried about. With Bitstream Vera Mono, the composed glyph ends
> up being from Latin Modern Roman, which looks very different.
>
> The composed glyphs for U+20D0..U+20FF look pretty bad in all the
> fonts Iʼve tried so far: Unifont, FreeSans, Free Mono, Menlo,
> Bitstream Vera Mono. Does anyone have an idea of a good font for
> those?
I'll let people comment on whether this is worth an optional
behavior.
> +static bool
> +codepoint_is_combining_lookup_eligible (int ch)
> +{
> + if ((0x20D0 <= ch && ch <= 0x20FF) || ch == 0x308)
> + return true;
> + return false;
> +}
Any reason not to use the Unicode category here? Or do we want to
support only specific characters (in which case U+0308 is still not
the only one)?
- bug#54562: 28.0.91; Emoji sequence not composed, (continued)
- bug#54562: 28.0.91; Emoji sequence not composed, Robert Pluim, 2022/03/25
- bug#54562: 28.0.91; Emoji sequence not composed, Po Lu, 2022/03/25
- bug#54562: 28.0.91; Emoji sequence not composed, Eli Zaretskii, 2022/03/26
- bug#54562: 28.0.91; Emoji sequence not composed, Lars Ingebrigtsen, 2022/03/26
- bug#54562: 28.0.91; Emoji sequence not composed, Po Lu, 2022/03/26
- bug#54562: 28.0.91; Emoji sequence not composed, Robert Pluim, 2022/03/27
- 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 <=
- 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, 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, 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