https://bugs.kde.org/show_bug.cgi?id=429742
Adam Fontenot <adam.m.fontenot+...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |adam.m.fontenot+kde@gmail.c
| |om
--- Comment #7 from Adam Fontenot <adam.m.fontenot+...@gmail.com> ---
I've written and deleted several long comments now because I keep discovering
new facets of this problem. Suffice it to say:
1. I see this issue on an updated Arch Linux system.
2. One variant of the trans flag emoji works, and one doesn't. If I copy the
trans flag emoji used on this page from my browser, I get the codepoints 1F3F3
FE0F 200D 26A7 FE0F. This does not work in QT / KDE applications. However, if
you can manage to find a 1F3F3 200D 26A7 somewhere[1], it will work. Another
example: the fully-qualified rainbow flag π³οΈβπ doesn't work, the unqualified
rainbow flag π³βπ does. (It's possible the KDE bug server or my browser may have
changed the representation of these characters, breaking the example.)
3. The difference between broken and working emoji is that the broken emoji all
contain an *emoji presentation selector* [2] in the *middle* of a emoji
character (usually right before a 200D zero width join).
4. This seems likely to be a bug with the QT text rendering engine.[3] It's not
really surprising that not many people have noticed it. A search says that
there are only around 250 qualified / unqualified pairs in Unicode 13.1, and
nearly all of these are things like the reminder ribbon π which will display
just fine because the presentation selector comes at the end of the character
*AND* because most fonts don't have a "text" representation of this emoji - so
it falls back to the emoji font correctly. It's made doubly complicated by the
fact that if you happen to copy an unqualified emoji it will (probably) work
just fine. A rare exception: "smiling face" βΊοΈ doesn't work for me in KDE apps.
That's because ignoring the trailing presentation selector results in my base
font rendering the text version of the glyph. (If you have a default font set
that is explicitly designed to fall back to your emoji font, it's likely that
it will not have many of these characters and so you'll see even *fewer*
issues.)
5. This is closely related to another bug I discovered: QT applications will
display a broken emoji if it contains a character used in your base font. For
example, "man kneeling" π§ββοΈ displays as π§+ β in KWrite because my selected font
(Source Code Pro) contains the β symbol. This might be the result of an
incorrect fontconfig, but I don't believe that's likely for the reasons given
in 6. If anyone can help me further drill down on the cause (even if that means
filing another bug) I'd be appreciative.
6. With my current configuration, I see no issue in Firefox, gedit, or
pango-view (a simple application that tests pango/cairo directly). For example,
`pango-view -t "π³οΈββ§οΈ"` displays the transgender flag emoji in a window as
expected. This further solidifies my view that the QT rendering engine has one
or more bugs. I'm not fully certain whether the problem I describe in 5 is the
same issue as what's reported here or not.
Let me know if there's anything I can do to help get this fixed.
[1] https://www.unicode.org/Public/emoji/14.0/emoji-test.txt
[2] https://unicode.org/reports/tr51/#def_emoji_presentation_selector
[3] I noticed that there's special handling for a ZWJ coming after a glyph
handled by a fallback font, but no such handling for an emoji presentation
selector. Could that be the source of the problem?
https://codereview.qt-project.org/gitweb?p=qt/qtbase.git;a=blob;f=src/gui/text/qfontengine.cpp#l1844
--
You are receiving this mail because:
You are watching all bug changes.
