See: U+FE0E (text-style selector) ignored when COLRv1 emoji fonts are present When a COLRv1 emoji font (e.g., Noto-COLRv1.ttf) is installed, the Unicode variation selector U+FE0E (text-style) is ignored, and emoji are always rendered in color. This breaks expected behavior, as U+FE0E should force monochrome rendering. Steps to reproduce: On a system with Noto-COLRv1.ttf (e.g., Fedora Rawhide), run: pango-view --font="sans" test.txt with the test.txt attached here: test.txt (this file contains: 🚀 🚀︎ (U+1F680 U+1F680 U+FE0E)) Expected output shown by pango-view: One colored rocket, one monochrome rocket. Actual output: two colored rockets. If one tries the same on Fedora 42 with default fonts installed, i.e. no font with a COLR table, it works as expected. /usr/share/fonts/google-noto-color-emoji-fonts/Noto-COLRv1.ttf does not have U+FE0E according to fontconfig: mfabian@f42:~ $ fc-list :charset=1f680,fe0e /usr/share/fonts/gdouros-symbola/Symbola.ttf: Symbola:style=Regular /usr/share/fonts/google-noto-emoji-fonts/NotoEmoji-Regular.ttf: Noto Emoji:style=Regular mfabian@f42:~ $ fc-list :charset=1f680 /usr/share/fonts/twemoji/Twemoji.ttf: Twemoji:style=Regular /usr/share/fonts/google-noto-color-emoji-fonts/NotoColorEmoji.ttf: Noto Color Emoji:style=Regular /usr/share/fonts/hfg-gmuend-openmoji-black-fonts/OpenMoji-black-glyf.ttf: OpenMoji Black,OpenMoji Black:style=Regular,Regular /usr/share/fonts/gdouros-symbola/Symbola.ttf: Symbola:style=Regular /usr/share/fonts/google-noto-emoji-fonts/NotoEmoji-Regular.ttf: Noto Emoji:style=Regular /usr/share/fonts/hfg-gmuend-openmoji-color-fonts/OpenMoji-color-glyf_colr_1.ttf: OpenMoji Color,OpenMoji Color:style=Regular, Regular mfabian@f42:~ $ and it is not used to render U+1F680 U+FE0E, instead /usr/share/fonts/google-noto-emoji-fonts/NotoEmoji-Regular.ttf is used which has both U+1F680 and U+FE0E. Reproducible: Always
Fixed already upstream in this merge request: https://gitlab.gnome.org/GNOME/pango/-/merge_requests/880
FEDORA-2025-1c6b7a6512 (pango-1.57.0-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-1c6b7a6512
At first glance this doesn't seem critical enough to me to justify a freeze exception. Jens, please provide some justification why this should break the freeze, thank you.
(In reply to Kamil Páral from comment #3) > At first glance this doesn't seem critical enough to me to justify a freeze > exception. Jens, please provide some justification why this should break the > freeze, thank you. You are probably right - though I think it would be good to have the newer pango version. Arguably pango could have been included in the Gnome Beta/RC Update...
Withdrawing the freeze exception request based on this comment: https://pagure.io/fedora-qa/blocker-review/issue/1901#comment-984842
FEDORA-2025-1c6b7a6512 (pango-1.57.0-1.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.