You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use a different client (not known to me) which generates fully-qualified emoji without unnecessary VS16s to add another thumbs-up to the same message
Observe two separate thumbs-up reactions that don't get grouped
Outcome
What did you expect?
Both thumbs-up reactions get grouped together, if they represent the same grapheme (i.e. both have the same visual representation), i.e. if an emoji without a text-representation has a superfluous VS16, it is grouped with the same emoji without.
Element should perhaps not generate unnecessary variation selectors and should maybe normalise emoji to their minimal representation that is still fully-qualified for reactions. This should probably still account for explicitly text-mode emoji (unclear if unqualified, clear if followed by VS15/U+FE0E), if those are intended to be supported.
What happened instead?
The visually identical reactions were grouped/counted separately.
Element generated U+1F44D U+FE0F (left in the image), while another client generated U+1F44D (right in the image), which according to https://unicode.org/Public/emoji/latest/emoji-test.txt is already fully-qualified and hence needs no VS16 (U+FE0F) to my knowledge.
The Element Android Emoji picker seems to generate a thumbs-up without VS16
hcsch
changed the title
Emoji picker generates thumbs-up emoji with unnecessary VS16
Emoji reactions with identical visual results are not grouped due to unnecessary VS16s
Apr 14, 2024
If this is an emoji, it should include the unicode emoji presentation selector (\uFE0F) for codepoints which allow it (see the emoji variation sequences list).
Steps to reproduce
Outcome
What did you expect?
Both thumbs-up reactions get grouped together, if they represent the same grapheme (i.e. both have the same visual representation), i.e. if an emoji without a text-representation has a superfluous VS16, it is grouped with the same emoji without.
Element should perhaps not generate unnecessary variation selectors and should maybe normalise emoji to their minimal representation that is still fully-qualified for reactions. This should probably still account for explicitly text-mode emoji (unclear if unqualified, clear if followed by VS15/U+FE0E), if those are intended to be supported.
What happened instead?
The visually identical reactions were grouped/counted separately.
Element generated U+1F44D U+FE0F (left in the image), while another client generated U+1F44D (right in the image), which according to https://unicode.org/Public/emoji/latest/emoji-test.txt is already fully-qualified and hence needs no VS16 (U+FE0F) to my knowledge.
Operating system
NixOS 24.05 (nixos-unstable)
Application version
Element version: 1.11.63 Crypto version: Rust SDK 0.7.0 (b1918e9), Vodozemac 0.5.1
How did you install the app?
Via NixOS package management
Homeserver
matrix.org
Will you send logs?
No
The text was updated successfully, but these errors were encountered: