-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
fonts: Respect emoji variation selector when selecting fonts #32493
Conversation
Hrm...there seems to be some kind of problem with this on macOS. I'm investigating now... |
7667053
to
6657aaf
Compare
Now that we are selecting fonts based on the emoji presentation needs, this change revealed an issue where we were too readily choosing emoji presentation. Instead of requesting it for every possible emoji character in the absence of an explicit emoji variation selection, we should only do it for characters that have an emoji presentation themselves. For example, "0" is classified as an "emoji character" by |
6657aaf
to
a8fbf36
Compare
🔨 Triggering try run (#9516395313) for Linux WPT |
Test results for linux-wpt-layout-2020 from try job (#9516395313): Flaky unexpected result (16)
Stable unexpected results that are known to be intermittent (11)
Stable unexpected results (1)
|
Test results for linux-wpt-layout-2013 from try job (#9516395313): Flaky unexpected result (12)
Stable unexpected results that are known to be intermittent (6)
Stable unexpected results (7)
|
|
a8fbf36
to
60bea62
Compare
🔨 Triggering try run (#9517614268) for Linux WPT |
I've had to modify this a bit. Now this explicitly handles characters that are emoji, but without emoji presentation, such as '☺'. These kind of characters should explicitly avoid emoji-like fonts unless they are paired with an emoji variation selector. |
I have chosen to add a new mode |
Test results for linux-wpt-layout-2020 from try job (#9517614268): Flaky unexpected result (15)
Stable unexpected results that are known to be intermittent (13)
|
✨ Try run (#9517614268) succeeded. |
I'll go ahead and land this one. There are some changes since the last review, these are mostly minor. |
This uses a pretty simple heuristic to select a font likely to contain color emoji. In the future Servo should actually check if the font also contains a color representation of the character in question. For now the code assumes that when a font supports color glyphs of some kind and supports the character in question at all, it supports the color version. This fixes support for rendering keycap emoji clusters such as 1️⃣ . Co-authored-by: Rakhi Sharma <atbrakhi@igalia.com> Co-authored-by: Mukilan Thiyagarajan <mukilan@igalia.com> Signed-off-by: Martin Robinson <mrobinson@igalia.com>
60bea62
to
4c8e758
Compare
This uses a pretty simple heuristic to select a font likely to contain
color emoji. In the future Servo should actually check if the font also
contains a color representation of the character in question. For now
the code assumes that when a font supports color glyphs of some kind and
supports the character in question at all, it supports the color
version.
This fixes support for rendering keycap emoji clusters such as 1️⃣ .
Co-authored-by: Rakhi Sharma atbrakhi@igalia.com
Co-authored-by: Mukilan Thiyagarajan mukilan@igalia.com
Signed-off-by: Martin Robinson mrobinson@igalia.com
./mach build -d
does not report any errors./mach test-tidy
does not report any errors