Skip to content

Conversation

@richardhozak
Copy link

@richardhozak richardhozak commented Nov 16, 2024

This reverts commit 66288ab.

Fixes #327

Note that putting "Noto Color Emoji" anywhere lower (even just below "DejaVu Sans") creates issue described in #327

Putting it above "Noto Sans" breaks text rendering completely.

With the commit reverted I cannot reproduce the original issue #68 the commit 66288ab was supposed to fix.

This reverts commit 66288ab.

Note that putting "Noto Color Emoji" anywhere lower (even just below "DejaVu Sans")
creates issue described in pop-os#327

Putting it above "Noto Sans" breaks text rendering completely.

With the commit reverted I cannot reproduce the original issue
pop-os#68 the commit
66288ab was supposed to fix.
@richardhozak
Copy link
Author

For posterity here are some screenshots...

With this PR:
Screenshot from 2024-11-16 21-50-52

When "Noto Color Emoji" is first in the array (above "Noto Sans"), text rendering breaks completely, but emojis work:
Screenshot from 2024-11-16 21-50-00

When "Noto Color Emoji" is just below "DejaVu Sans", text rendering does not display emojis properly:
image

@jackpot51
Copy link
Member

Perhaps @hecrj can check if this works okay on their system?

@hecrj
Copy link
Contributor

hecrj commented Jan 10, 2025

@jackpot51 Just tried it and I have the same issues:

image

I don't have Noto Sans installed, so it's choosing the emoji font as fallback for many glyphs.

I don't think an emoji font should be that high in the fallback sequence.

@hecrj
Copy link
Contributor

hecrj commented Jan 10, 2025

I believe a proper fix would be to have a separate emoji fallback list and have some kind of emoji detection during font selection.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Inconsistent emoji rendering

3 participants