Subject: Re: bug#54562: 28.0.91; Emoji sequence not composed

From: Robert Pluim <[email-masked]>
Date: Tue, 29 Mar 2022 12:45:44 +0200

>>>>> On Mon, 28 Mar 2022 19:07:53 +0300, Eli Zaretskii <[email-masked]> said:

    >> From: Robert Pluim <[email-masked]>
    >> Cc: [email-masked],  [email-masked],  [email-masked]
    >> Date: Mon, 28 Mar 2022 16:59:16 +0200
    >> 
    >> >> +static bool
    >> >> +codepoint_is_combining_lookup_eligible (int ch)
    >> >> +{
    >> >> +  if ((0x20D0 <= ch && ch <= 0x20FF) || ch == 0x308)
    >> >> +    return true;
    >> >> +  return false;
    >> >> +}
    >> 
    Eli> Any reason not to use the Unicode category here?  Or do we want to
    Eli> support only specific characters (in which case U+0308 is still not
    Eli> the only one)?
    >> 
    >> You'd want to apply this to everything in Mn? Thatʼs a lot of
    >> codepoints. Or did you mean Me? Or anything in Mn thatʼs latin? The
    >> possibilities are endless :-)

    Eli> I thought about any Mn character whose canonical-combining-class
    Eli> property is 200 and above.  The COMBINING ENCLOSING <SOMETHING> stuff
    Eli> will need to be added to that, of course.  And we could have that
    Eli> option have multiple possible values, not just on/off...

OK. Would Me be ok for you, or would you specifically want only the
codepoints from the "Combining Diacritical Marks for Symbols" block?

I guess you'd want options like:

'all => combining-class + enclosing
'enclosing
'combining-class

(did we want to cover the 'number followed U+20E3 => emoji' case with
an option too?)

    Eli> Btw, for sequences that include a base character and 2 or more
    Eli> diacritics, selecting a font that supports the first diacritic (the
    Eli> one which triggers the composition) might not be enough, since the
    Eli> rest of the diacritics could be absent from that font.  Instead, we'd
    Eli> need something like "find the font for each one of them and then use
    Eli> the one which supports the largest subset of them".

font_range currently only has access to the first diacritic, so that
would be a bigger change. And that subset had better have the same
size as the number of unique diacritics, otherwise itʼs unlikely to
work.

Robert
--