Bug 197838 – [FreeType] Some character sequences with a variation selector are not rendered

• Status: RESOLVED
• Resolution: FIXED
• Component: Text

[Carlos Garcia Campos]

We get the invalid glyph instead. See http://mts.io/2015/04/21/unicode-symbol-render-text-emoji/ In the table at the end the Emoji and Text columns are not correctly rendered. It happens also when copying an emoji from GtkEmojiChooser and pasting in WebKit text field, because GTK appends U+FE0F to all emojis to force the emoji style.

[Carlos Garcia Campos]

Created attachment 369732 [details]
Patch

I've tried to make a test for this, but it's not easy, at least not for GTK, because I get different width/height offset when rendering directly with emoji font than when falling back to it. I don't know why. The thing is that a ref test always fails with very few pixels difference.

[EWS Watchlist]

Comment on attachment 369732 [details]
Patch

Attachment 369732 [details] did not pass win-ews (win):
Output: https://webkit-queues.webkit.org/results/12185244

New failing tests:
http/tests/security/local-video-src-from-remote.html

[EWS Watchlist]

Created attachment 369824 [details]
Archive of layout-test-results from ews212 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews212  Port: win-future  Platform: CYGWIN_NT-10.0-17763-3.0.5-338.x86_64-x86_64-64bit

[Michael Catanzaro]

Comment on attachment 369732 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=369732&action=review

> Source/WebCore/ChangeLog:11
> +        style. We need to take into account the variaiton selector when checking if a font can render a combining

variation

[Carlos Garcia Campos]

Committed r245393: <https://trac.webkit.org/changeset/245393>

[Radar WebKit Bug Importer]

<rdar://problem/50846399>