On Fri Mar 20 08:30:53 2026 +0000, Nikolay Sivov wrote:
Which distro/package is it from? I'd like to try such combination on older Windows, to see what dwrite reports for it. The one hosted here https://fonts.google.com/noto/specimen/Noto+Color+Emoji does have glyf data as well as COLRv1 table, so it should in theory work if regular outlines are reasonable. But, if your copy only has COLRv1 and nothing else, a better place to reject it would be opentype_ttf_analyzer(). For example checking if COLRv1 is available, but glyf is missing. 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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10388#note_133049