bug#55319: 28.1.50; Abugida not rendered correctly (MacOS)

[Eli Zaretskii <eliz@gnu.org>]

> From: Kai Ma <justksqsf@gmail.com>
> Date: Mon, 9 May 2022 09:43:48 +0800
> Cc: 55319@debbugs.gnu.org
> 
> > On May 9, 2022, at 00:57, Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> > Emacs doesn't OOTB support scripts whose characters are not in
> > Unicode.  When characters are not in Unicode, their properties and
> > attributes aren't known, unless someone tells Emacs what they are.
> 
> That was my thought, too. However, I don’t think this is the root cause in this case.
> 
> 1. Other applications (including Web browsers and the native GUI toolkit) render 
>   the text just fine. This makes me believe the font file itself contains enough information.

I don't know about other applications and their needs, but I do know
what Emacs needs to support a character.  A font cannot contain enough
information for Emacs to use a character in general, and doesn't even
include enough information for Emacs to display that character.  More
importantly, Emacs never takes information about characters from
fonts.  It's actually the other way around: Emacs needs to know enough
about a character to choose the right font for it.

> 2. Emacs also discovers some glyphs should be composed, e.g. intonation marks (e.g. #xed8c), 
>   but not the vowels. I don’t know why this happens. I just tried copy character properties 
>   from these good ones. It didn’t work.

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).

> But in general, this could just be Emacs not fully supporting OpenType features.

Emacs relies on text-shaping engines for full OTF support.  AFAIK,
text-shaping engines also don't support PUA characters without special
measures.