GNU bug report logs - #50177
Support U+20DD COMBINING ENCLOSING CIRCLE

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 50177 in the body.
You can then email your comments to 50177 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Support U+20DD COMBINING ENCLOSING CIRCLE
Date: Tue, 24 Aug 2021 07:14:17 +0800

How do
檢⃝  x⃝
look to you?

In https://bugs.chromium.org/p/chromium/issues/detail?id=1242732#c2
only Firefox puts them in the circles.

Emacs is at least a little better than chrome, but still puts the circle
at back, instead of around.

emacs-version "27.1"

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: 50177 <at> debbugs.gnu.org
Subject: Re: bug#50177: Support U+20DD COMBINING ENCLOSING CIRCLE
Date: Tue, 24 Aug 2021 14:54:58 +0300

> From: 積丹尼 Dan Jacobson
>  <jidanni <at> jidanni.org>
> Date: Tue, 24 Aug 2021 07:14:17 +0800
> 
> How do
> 檢⃝  x⃝
> look to you?

Look correctly: as a single grapheme cluster.

> In https://bugs.chromium.org/p/chromium/issues/detail?id=1242732#c2
> only Firefox puts them in the circles.
> 
> Emacs is at least a little better than chrome, but still puts the circle
> at back, instead of around.

You need a font that has glyphs for both the character and the circle.
Emacs can only compose character glyphs from the same font.

I see no bug here.

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

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 50177 <at> debbugs.gnu.org
Subject: Re: bug#50177: Support U+20DD COMBINING ENCLOSING CIRCLE
Date: Tue, 24 Aug 2021 21:39:21 +0800

>>>>> "EZ" == Eli Zaretskii <eliz <at> gnu.org> writes:
>> How do
>> 檢⃝  x⃝
>> look to you?

EZ> Look correctly: as a single grapheme cluster.

EZ> You need a font that has glyphs for both the character and the circle.
EZ> Emacs can only compose character glyphs from the same font.

OK, it's a deal. On debian what package can I install to prove your theory?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 50177 <at> debbugs.gnu.org,
 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Subject: Re: bug#50177: Support U+20DD COMBINING ENCLOSING CIRCLE
Date: Tue, 24 Aug 2021 17:30:13 +0200

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> How do
>> 檢⃝  x⃝
>> look to you?
>
> Look correctly: as a single grapheme cluster.

I'm getting:

[Message part 2 (image/png, inline)]

[Message part 3 (text/plain, inline)]

But indeed, the x and the ⃝ are from different fonts, so this isn't
surprising.

We have a number of open bug reports in this area.  At least 44784,
23292, 17739, which may or may not be the same underlying problem.
(Probably different issues, really.)

I haven't looked at the machinery here at all -- is there a fundamental
reason why Emacs can't combine glyphs from different fonts?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: 50177 <at> debbugs.gnu.org
Subject: Re: bug#50177: Support U+20DD COMBINING ENCLOSING CIRCLE
Date: Tue, 24 Aug 2021 19:25:32 +0300

> From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
> Cc: 50177 <at> debbugs.gnu.org
> Date: Tue, 24 Aug 2021 21:39:21 +0800
> 
> >>>>> "EZ" == Eli Zaretskii <eliz <at> gnu.org> writes:
> >> How do
> >> 檢⃝  x⃝
> >> look to you?
> 
> EZ> Look correctly: as a single grapheme cluster.
> 
> EZ> You need a font that has glyphs for both the character and the circle.
> EZ> Emacs can only compose character glyphs from the same font.
> 
> OK, it's a deal. On debian what package can I install to prove your theory?

I don't know, I'm not a Debian user.

Lars, can you help here?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Kenichi Handa <handa <at> gnu.org>
Cc: 50177 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#50177: Support U+20DD COMBINING ENCLOSING CIRCLE
Date: Tue, 24 Aug 2021 19:38:56 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
>   50177 <at> debbugs.gnu.org
> Date: Tue, 24 Aug 2021 17:30:13 +0200
> 
> We have a number of open bug reports in this area.  At least 44784,
> 23292, 17739, which may or may not be the same underlying problem.
> (Probably different issues, really.)

44784 and 23292 are due to a problematic font (DejaVu Sans Mono).
17739 -- not clear.

> I haven't looked at the machinery here at all -- is there a fundamental
> reason why Emacs can't combine glyphs from different fonts?

The basic reason is that glyphs from different fonts cannot combine
well because they were designed to look differently, and so offsets
don't match.  That is almost certainly the reason when we use our
fallback composition code in composite.el.  I'm less sure about modern
shaping engines like HarfBuzz -- we should ask their developers to be
sure; feel free to open an issue/question on their GitHub.

CC'ing Handa-san, in the hope that he could explain better why we
disallow character composition from different fonts.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 50177 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#50177: Support U+20DD COMBINING ENCLOSING CIRCLE
Date: Wed, 25 Aug 2021 12:52:01 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> 44784 and 23292 are due to a problematic font (DejaVu Sans Mono).

OK; I've now merged those two.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: handa <handa <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: handa <at> gnu.org, 50177 <at> debbugs.gnu.org, larsi <at> gnus.org, jidanni <at> jidanni.org
Subject: Re: bug#50177: Support U+20DD COMBINING ENCLOSING CIRCLE
Date: Sat, 28 Aug 2021 15:28:03 +0900

In article <8335qyx0f3.fsf <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:
> > I haven't looked at the machinery here at all -- is there a fundamental
> > reason why Emacs can't combine glyphs from different fonts?

> The basic reason is that glyphs from different fonts cannot combine
> well because they were designed to look differently, and so offsets
> don't match.  That is almost certainly the reason when we use our
> fallback composition code in composite.el.  I'm less sure about modern
> shaping engines like HarfBuzz -- we should ask their developers to be
> sure; feel free to open an issue/question on their GitHub.

> CC'ing Handa-san, in the hope that he could explain better why we
> disallow character composition from different fonts.

The main reason is what Eli wrote. An opentype font contains rules to
tell how to compose two glyphs in that font.  But such rules are
specific to that font, and there's no way to combine rules of different
fonts.  So, an opentype rendering engine does not work for different
fonts.

And, when we artificially compose characters from different fonts, there
is a possibility that the resulting image looks like a different
character which I think is worse than not composing.

---
K. Handa
handa <at> gnu.org

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

From: Werner LEMBERG <wl <at> gnu.org>
To: handa <at> gnu.org
Cc: 50177 <at> debbugs.gnu.org, eliz <at> gnu.org, larsi <at> gnus.org, jidanni <at> jidanni.org
Subject: Re: bug#50177: Support U+20DD COMBINING ENCLOSING CIRCLE
Date: Sat, 28 Aug 2021 06:40:02 +0000 (UTC)

>> CC'ing Handa-san, in the hope that he could explain better why we
>> disallow character composition from different fonts.
> 
> The main reason is what Eli wrote. An opentype font contains rules
> to tell how to compose two glyphs in that font.  But such rules are
> specific to that font, and there's no way to combine rules of
> different fonts.  So, an opentype rendering engine does not work for
> different fonts.
> 
> And, when we artificially compose characters from different fonts,
> there is a possibility that the resulting image looks like a
> different character which I think is worse than not composing.

+1


    Werner

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: handa <handa <at> gnu.org>
Cc: 50177 <at> debbugs.gnu.org, larsi <at> gnus.org, jidanni <at> jidanni.org
Subject: Re: bug#50177: Support U+20DD COMBINING ENCLOSING CIRCLE
Date: Sat, 28 Aug 2021 10:32:26 +0300

> From: handa <handa <at> gnu.org>
> Cc: larsi <at> gnus.org, jidanni <at> jidanni.org, 50177 <at> debbugs.gnu.org, handa <at> gnu.org
> Date: Sat, 28 Aug 2021 15:28:03 +0900
> 
> In article <8335qyx0f3.fsf <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:
> > > I haven't looked at the machinery here at all -- is there a fundamental
> > > reason why Emacs can't combine glyphs from different fonts?
> 
> > The basic reason is that glyphs from different fonts cannot combine
> > well because they were designed to look differently, and so offsets
> > don't match.  That is almost certainly the reason when we use our
> > fallback composition code in composite.el.  I'm less sure about modern
> > shaping engines like HarfBuzz -- we should ask their developers to be
> > sure; feel free to open an issue/question on their GitHub.
> 
> > CC'ing Handa-san, in the hope that he could explain better why we
> > disallow character composition from different fonts.
> 
> The main reason is what Eli wrote. An opentype font contains rules to
> tell how to compose two glyphs in that font.  But such rules are
> specific to that font, and there's no way to combine rules of different
> fonts.  So, an opentype rendering engine does not work for different
> fonts.
> 
> And, when we artificially compose characters from different fonts, there
> is a possibility that the resulting image looks like a different
> character which I think is worse than not composing.

OK, thanks.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: handa <handa <at> gnu.org>, jidanni <at> jidanni.org, 50177 <at> debbugs.gnu.org
Subject: Re: bug#50177: Support U+20DD COMBINING ENCLOSING CIRCLE
Date: Sun, 14 Nov 2021 07:49:56 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> And, when we artificially compose characters from different fonts, there
>> is a possibility that the resulting image looks like a different
>> character which I think is worse than not composing.
>
> OK, thanks.

Then it seems like things here are working as designed, and I'm closing
this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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