Text-only emoji, that is to say, emoji that appears in
user/server/channel names, turns the whole line blank with a
ridiculous line height. Emoji rendered as images are not affected.

I can consistently replicate this on Arch but not on Debian. cancel
says this has to do with Arch's Qt version.

So we think what's going on here is that the regular non-chat-log font that is being chosen has a serious problem with particular emoji.

The "regular" UI font, which is used on stuff like buttons, some list views, the status bar, etc. really doesn't like certain emoji. Freetype is screwing up and drawing way outside of the bounds it should be.

Ripcord doesn't clean up the pixel buffers outside of where the name text is supposed to be drawn in the status bar. So if Freetype goes psycho and scribbles all over the pixel buffer, Ripcord won't know to clear it from there and redraw the normal UI colors - it'll just leave the garbage there until something else needs to repaint over it.

It costs CPU to repaint stuff. If something hasn't changed, you don't want to repaint it. So Ripcord, in general, only repaints areas that actually need it. For example, in the status bar, if someone is typing, when it draws the text "dude is typing..." it remembers the size/bounds of the drawn text; then when it comes time to clear it when the person finishes typing, it only redraws the normal UI color over that area - it doesn't clear the entire status bar or the whole window.

But if Freetype goes crazy and draws pixels outside of where it should, Ripcord has no idea that it needs to clear that area too, since Freetype wasn't supposed to be drawing there in the first place. It's obviously a glitch in Freetype, since it's not correctly reporting the area that it ended up painting over - so the code in Freetype is screwing up and not correctly keeping track of the area it's painting over, and lying to Ripcord about which pixels were painted.

(to be fair, all of the font rendering APIs on all of the platforms have this problem to some degree)

There are things you can do to mitigate it, like fencing the pixel buffer mutations using clipping rectangles, but that slows down painting. So Ripcord usually only uses clipping rectangles to guard against different widgets drawing on top of each other, which is why the name is still clipped to the status bar widget itself - even though the text is outside of the bounds it should be, it doesn't end up being painted on top of the chat log or input area.

cancel isn't yet sure how he could add code in Ripcord to test for corrupt/broken emoji fonts. One idea is to create an off-screen pixel buffer, try drawing some emoji into it, and then testing to see if any pixels were drawn out of bounds.

This is definitely a Linux-only problem though, and it only seems to affect text outside of the chat log, since the chat log text uses Ripcord's own emoji system (but menus, regular buttons, user names, etc. use the regular font/emoji rendering system).

I was able to fix this issue on my own Arch Linux installation by removing all emoji-providing fronts from my system, and then installing ttf-twemoji-color.

AUR: https://aur.archlinux.org/packages/ttf-twemoji-color/

Github: https://github.com/eosrei/twemoji-color-font

Quick note: I think this is from the distro's/system's FreeType, not Qt. Ripcord bundles Qt in the AppImage but not FreeType.

In addition to EmojiOne and Noto Color, Twemoji doesn't work (on my end) as well. Actually I haven't found a single colour emoji that works, so I ended up falling back to Symbola.

If you have problems with emoji (and some CJKV characters) not displaying even with Symbola, you need to specify fallback fonts in your fonts.conf.