GNU bug report logs -
#20173
24.4; Rendering misallocates combining marks on ligatures
Previous Next
Full log
Message #14 received at 20173 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 23 Mar 2015 22:41:07 +0000
> From: Richard Wordingham <richard.wordingham <at> ntlworld.com>
> Cc: 20173 <at> debbugs.gnu.org
>
> On Mon, 23 Mar 2015 17:38:52 +0200
> Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > > Date: Mon, 23 Mar 2015 01:06:26 +0000
> > > From: Richard Wordingham <richard.wordingham <at> ntlworld.com>
>
> > Is it possible that some rule(s) are missing from the end of
> > lisp/language/misc-lang.el? Could you please take a look and see if
> > something needs to be fixed/added in how we set up the compositions
> > for Arabic?
>
> There's no relevant problem there. I demonstrated the bug to myself by
> first rendering Tai Tham <NA, TONE-2, SIGN AA> and confirming that
> TONE-2 rendered above the first component of the ligature NAA, fromed
> from <NA, SIGN AA>. I then hacked my font so that the glyph for TONE-2
> was decomposed into the glyphs for MAI KANG and TONE-2, in that order,
> and observing TONE-2 being rendered on the second component of the
> ligature. I then turned to Arabic so that a custom font would not be
> needed to demonstrate the bug.
Sorry, I'm not sure I understand you. If the setting of composition
rules for Arabic is not the culprit, then what is? AFAIK, there are
no rules that guide Emacs's shaping except what's in
composition-function-table. Beyond that, the only other factor is the
font backend and how it shapes glyphs given the chunks of text Emacs
presents to it.
> As to what needs fixing in the Arabic section of misc-lang.el:
Thanks, I will look into these.
This bug report was last modified 4 years and 282 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.