bug#50177: Support U+20DD COMBINING ENCLOSING CIRCLE

bug#50177: Support U+20DD COMBINING ENCLOSING CIRCLE

[積丹尼 Dan Jacobson]

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"

bug#50177: Support U+20DD COMBINING ENCLOSING CIRCLE

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson
>  <jidanni@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.

bug#50177: Support U+20DD COMBINING ENCLOSING CIRCLE

[積丹尼 Dan Jacobson]

>>>>> "EZ" == Eli Zaretskii <eliz@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?

bug#50177: Support U+20DD COMBINING ENCLOSING CIRCLE

[Lars Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 155 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

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

I'm getting:


[-- Attachment #2: Type: image/png, Size: 1884 bytes --]

[-- Attachment #3: Type: text/plain, Size: 507 bytes --]


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

bug#50177: Support U+20DD COMBINING ENCLOSING CIRCLE

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
> Cc: 50177@debbugs.gnu.org
> Date: Tue, 24 Aug 2021 21:39:21 +0800
> 
> >>>>> "EZ" == Eli Zaretskii <eliz@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?

bug#50177: Support U+20DD COMBINING ENCLOSING CIRCLE

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 積丹尼 Dan Jacobson <jidanni@jidanni.org>,
>   50177@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.

bug#50177: Support U+20DD COMBINING ENCLOSING CIRCLE

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

bug#50177: Support U+20DD COMBINING ENCLOSING CIRCLE

[handa]

In article <8335qyx0f3.fsf@gnu.org>, Eli Zaretskii <eliz@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@gnu.org

bug#50177: Support U+20DD COMBINING ENCLOSING CIRCLE

[Werner LEMBERG]

>> 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

bug#50177: Support U+20DD COMBINING ENCLOSING CIRCLE

[Eli Zaretskii]

> From: handa <handa@gnu.org>
> Cc: larsi@gnus.org, jidanni@jidanni.org, 50177@debbugs.gnu.org, handa@gnu.org
> Date: Sat, 28 Aug 2021 15:28:03 +0900
> 
> In article <8335qyx0f3.fsf@gnu.org>, Eli Zaretskii <eliz@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.

bug#50177: Support U+20DD COMBINING ENCLOSING CIRCLE

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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