GNU bug report logs -
#54562
28.0.91; Emoji sequence not composed
Previous Next
Full log
Message #80 received at 54562 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: luangruo <at> yahoo.com, larsi <at> gnus.org, 54562 <at> 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)?
This bug report was last modified 3 years and 133 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.