GNU bug report logs - #39799
28.0.50; Most emoji sequences don’t render correctly

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: rgm <at> gnu.org, 39799 <at> debbugs.gnu.org, mfabian <at> redhat.com
Subject: bug#39799: 28.0.50; Most emoji sequences don’t render correctly
Date: Fri, 28 Feb 2020 22:16:21 +0200

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: rgm <at> gnu.org,  mfabian <at> redhat.com,  39799 <at> debbugs.gnu.org
> Date: Fri, 28 Feb 2020 17:39:56 +0100
> 
> I donʼt think that applies in this case. The sequences are all easily
> categorised based on the first char in the sequence. It could be done
> based on the 2nd, or 3rd or whatever, but I donʼt think that reduces
> the number of entries. Plus thereʼs always one rule per character,
> since multiple patterns starting with the same character are combined
> using regexp-opt.

I wrote that to describe the general considerations, not necessarily
because I think they are applicable in this particular case.  I didn't
analyze the sequences to see whether any of what I wrote can or should
be used for them.

> One thing though: the code currently does set-char-table-range to a
> new value. Is there a chance that an entry already exists in
> composition-function-table for a particular character?

Only if the non-leading character is a combining character, which I
think is unlikely.  But in general, yes, this should be tested up
front to avoid losing composition rules.

Previous Next

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