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

Previous Next

Full log

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.

Previous Next

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