GNU bug report logs - #55319
28.1.50; Abugida not rendered correctly (MacOS)

Previous Next

Full log

View this message in rfc822 format

From: Kai Ma <justksqsf <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 55319 <at> debbugs.gnu.org
Subject: bug#55319: 28.1.50; Abugida not rendered correctly (MacOS)
Date: Wed, 11 May 2022 23:43:36 +0800

[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)]

Previous Next

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