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

Previous Next

Full log

Message #39 received at 55319 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: justksqsf <at> gmail.com, 55319 <at> debbugs.gnu.org
Subject: Re: bug#55319: 28.1.50; Abugida not rendered correctly (MacOS)
Date: Thu, 12 May 2022 12:54:39 +0300

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: justksqsf <at> gmail.com,  55319 <at> debbugs.gnu.org
> Date: Thu, 12 May 2022 11:42:24 +0200
> 
> >>>>> On Thu, 12 May 2022 12:37:52 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
> 
>     >> From: Robert Pluim <rpluim <at> gmail.com>
>     >> Cc: 55319 <at> debbugs.gnu.org,  Eli Zaretskii <eliz <at> gnu.org>
>     >> Date: Thu, 12 May 2022 10:36:29 +0200
>     >> 
>     >> Eli, since these are PUA, can we still add them to Emacs?
> 
>     Eli> I don't think I understand what exactly would you like to add.
> 
> The composition rules that Kai Ma just produced.

Those composition rules assume a specific meaning to these PUA
codepoints.  But if someone uses those same PUA codepoints to express
other characters, the composition rules will no longer be valid for
that someone.

This is a general problem with PUA codepoints: their meaning is in the
eyes of the beholder.  We could perhaps provide some infrastructure
for making use of PUA codepoints easier than it is now.  We could even
provide opt-in packages, which, when loaded, assign specific meanings
to specific PUA codepoints.  But I don't see how we could _by_default_
assign some specific meaning to those codepoints, because there's no
basis for preferring one interpretation of them to another.

Previous Next

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