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

Previous Next

Package: emacs;

Reported by: Po Lu <luangruo <at> yahoo.com>

Date: Fri, 25 Mar 2022 09:18:02 UTC

Severity: normal

Found in version 28.0.91

Full log


Message #80 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: Mon, 28 Mar 2022 16:12:06 +0300
> 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.