GNU bug report logs -
#55319
28.1.50; Abugida not rendered correctly (MacOS)
Previous Next
Reported by: Kai Ma <justksqsf <at> gmail.com>
Date: Sun, 8 May 2022 16:23:01 UTC
Severity: wishlist
Found in version 28.1.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #24 received at 55319 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On May 9, 2022, at 10:38, Eli Zaretskii <eliz <at> gnu.org <mailto:eliz <at> gnu.org>> wrote:
>
> Emacs doesn't discover composition rules. The composition rules are
> part of the Emacs code, see the various *.el files in lisp/language/
> directory. Some of these composition rules are derived automatically
> from character properties, see composite.el and characters.el (which
> cannot happen without Emacs knowing up-front about the properties).
Thanks for this. I didn’t know Emacs needed to manually compose characters.
Feel free to close this report, since it is due to my misunderstanding, not a real problem nor a real “wishlist”.
BTW,
I did try to follow language/*.el, and come with up the following code:
(let* ((c "[\uED80-\uED9F]\\|\uEDAA\\|\uEDAB”) ; constant
(v "[\uEDA0-\uEDA9]”) ; vowel
(cv (concat v c)))
(set-char-table-range
composition-function-table '(#xeda0 . #xeda9)
(list
(vector cv 1 #'zbalermorna-shape-gstring)
[nil 0 font-shape-gstring])))
(defun zbalermorna-shape-gstring (gstring direction)
(message "shape %s" gstring) ; debugging
gstring)
But it doesn’t work as expected. For example, “ka” should be composed, but the behavior here is “a” itself is composed, and when the first rule is matched, only the consonant “k” is sent to font-shape-gstring: only “k” is in the header.
Have you any pointers? Thanks!
[Message part 2 (text/html, inline)]
This bug report was last modified 3 years and 15 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.