GNU bug report logs -
#20140
24.4; M17n shaper output rejected
Previous Next
Full log
View this message in rfc822 format
On Sun, 13 Feb 2022 21:49:04 +0200
Eli Zaretskii <eliz <at> gnu.org> wrote:
> > Date: Sat, 5 Feb 2022 22:52:51 +0000
> > From: Richard Wordingham <richard.wordingham <at> ntlworld.com>
> > Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 20140 <at> debbugs.gnu.org
> >
> > Sad to see that Khaled Hosny's suggestion not to use composition
> > rules seems not to have been taken.
>
> Btw, the _only_ reason Handa-san and now myself were able to implement
> something like the forward/backward-char-intrusive commands is that we
> DO control which parts of text are composed and which aren't. If we
> were to follow HarfBuzz developers' advice, and were to hand all the
> text to HarfBuzz for shaping, we would need the HarfBuzz cooperation
> to implement such features in the editor.
You mean the more sophisticated mechanisms which position the cursor
intelligently. Those two commands you named work by completely
ignoring the composition mechanism.
Correct me if I am wrong, but for Arabic, is not Emacs restricted to
typewriter-like fonts?
There would be a similar problem with the use of Tai Khuen or other
tunnelling fonts for Northern Thai if you used the current mechanism
for advancing character by character. Tunnelling fonts write parts of
one cluster under the next. The Tai Khuen fonts I've seen do this by
relying on characteristics of Tai Khuen spelling. The rules don't hold
for Northern Thai, and consequently the subscript portions of
successive orthographic syllables can overwrite one another. A
sophisticated font could check for clashes, but that needs the
orthographic syllables to be passed to the shaper together.
Richard.
This bug report was last modified 3 years and 155 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.