New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistent Emoji when sans-serif is Noto Sans CJK/Source Han Sans #31322
Comments
@ffoodd @patrickhlauke can we close this since #31960 has landed? |
@XhmikosR i think this is slightly different aspect. #31960 warns about unicode chars being replaced by emoji that then can't be styled colour-wise, while this issue highlights that in some cases the emoji fonts are not kicking in, if i understand it correctly ... i.e. the opposite issue of what #31960 describes. would reshuffling the order in which the fonts are called have any other adverse effects? if not, i'd say go for the suggested fix here (though to clarify, i assume this is just about moving the emoji fonts and not duplicating it like in the above code block?) |
Hesitant to merge this without a thorough test. Would someone want to jump in and explore? |
If I understand what's going on, those kick in as |
yes I believe that's, roughly, the request here in the thread starter. I think the only situation where this would have an adverse effect is where/if we/an author rely on a unicode char to kick in rather than an emoji char - but I believe that we've now consistenly moved to using SVGs rather than unicodes for things like "x" close controls, so can't think of situations where our components would be affected in any way. |
Agreed, and even in that case it'd only need some |
Bug report:
Steps:
Screenshot:
Suggested fix:
Put Emoji fonts in front of text fonts like
The text was updated successfully, but these errors were encountered: