Ticket UUID: | acaddd470e82d357bc7d0f84b3c8277a66d76c20 | |||
Title: | Channel names with a Unicode character or emoji show a garbled mess | |||
Status: | Open | Type: | Bug | |
Severity: | Minor | Priority: | Low | |
Subsystem: | Discord | Resolution: | Open | |
Last Modified: | 2021-02-07 07:51:08 | |||
Version Found In: | 0.4.28 | |||
5e86a6e7 — 2021-01-22 16:36:05Discord Channel name bug (May happen to users to)When it happens,
Images of it[Channel][https://imgur.com/a/W3TtKGR] [Username/Nickname][https://imgur.com/a/xik5SyV] | ||||
cancel — 2021-01-24 01:53:14 Is this on Linux? Please look at this, it's on the front page of the wiki: Do you see crazy corrupt text in some places in Ripcord on Linux? This is likely caused by a malformed emoji font and the FreeType installed on your system interacting with each other. See this ticket for details. If you're on Arch, you'll probably want to remove ttf-emojione-color and noto-fonts-emoji. | ||||
cobertos — 2021-02-04 20:18:22 I can confirm I'm getting the same issue on Linux Mint (fresh install) and not in Windows 10. I only have the issue with emojis, not all unicode characters it looks like? I am also getting this issue in url preview cards, like from Twitter. Here's some comparisons between the Electron Discord client and Ripcord: https://i.imgur.com/42jf3j7.png . It properly renders arrows and o with umlaut, but not evergreen tree. https://i.imgur.com/3Cv7Gjp.png . Doesn't render the card properly, each of the big corrupted blobs is a selectable character too x3 I will try the fix you linked | ||||
cobertos — 2021-02-05 18:47:41 Well, about a 6 hour rabbit hole. I one-by-one installed Noto, Twemoji, and Blobmoji (modified Noto), deleting all the others in between. I also tried manually using a fontconfig fonts.conf but found leaving it alone is the best option, relying on the fonts themselves to expose themselves to fontconfig properly without the other fonts being present (because some of them expose a charset that provides default characters for things like 20 (space), and 0-9, which causes some real issues if the fonts.conf precedence is too high for the emoji font). Between each font application I ran a The following is what I was able to find Noto Color Emoji: Not working, breaks RipCord, works everywhere else Blobmoji (based on Noto): Not working, breaks RipCord, works everywhere else Twemoji: Working in RipCord and everywhere else No Emoji font: Working in RipCord, shows missing character for emoji, didn't test elsewhere I was having issues with my earlier testing. I assume that even with a fonts.conf setup to try to provide precedence to a new font, it was still choosing the bundled Noto that comes with Linux Mint. I had to fully remove Noto Color Emoji from | ||||
cobertos — 2021-02-05 18:50:30 So Twemoji will work but you have to fully remove Noto Color Emoji because | ||||
cobertos — 2021-02-05 20:10:44 One last thing, it looks like you might be able to just pass Twemoji to only RipCord, by using Need to test this as well, but then that would at least mean RipCord could be given a font that works for it while everything else can still use cute Blobmojis or something. | ||||
cobertos — 2021-02-05 23:17:01 This isn't the best config, but I was able to provide RipCord with a working font (b/w Twemoji) and everything else gets Blobmoji. Had to do it this way because Twemoji was just, by default, higher in the precedence stack, due to Linux Mint/Ubuntu's default font configs Im pretty sure.
yayyy. Usage can be seen here https://github.com/Cobertos/dotfiles/blob/master/fonts/55-prefer-blobmoji-except-ripcord.conf | ||||
cancel — 2021-02-07 07:51:08 Nice research, thanks. |