On Fri Mar 20 14:37:34 2026 +0000, Paul Gofman wrote:
There are different versions of this font in packages (different released versions of the font), with or without glyf table, but the result is essentially the same at least WRT the emoji glyphs itself (example symbols are \`\`\`\\xD83D\\xDE04\`\`\` (0x1f604 **:smile:** ), \`\`\`\\xd83d\\xdcb0\`\`\` (0x1f4b0 :moneybag:). I think all of those can be found through the history of font releases here: https://github.com/googlefonts/noto-emoji/releases . * On Arch with noto-fonts-emoji 1:2.047-1 (NotoColorEmoji.ttf): doesn't have neither COLR nor GLYF, that is bitmap only CBDT font. This is a different story, such fonts also don't render currently, neither through GDI nor dwrite, I only had a brief look and maybe that is about freetype2 usage / requested glyph sizes but I am not fully sure, that needs a better look; * On Fedora google-noto-color-emoji-fonts-20250623-2.fc43.noarch (Noto-COLRv1.ttf): has both colr and glyf tables but the emojis don't render through emoji glyph neither as is nor with disabling FONT_IS_COLORED for it in opentype_get_font_properties(). That's both for dwrite with d2d1 (rendering with dwrite.CreateTextLayout / d2d1.DrawTextLayout) and for the CEF + game which doesn't use d2d, only generates dwrite runs. * The same is with the font linked above (NotoColorEmoji_regular.ttf). So if the font stays with glyf presence this is not solving anything in practice. I guess glyf table is not supposed to be used directly with COLR fonts? That is referenced from COLR table layers.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10388#note_133052