JDK-8303494 : [macos] Incorrect rendering and spacing of emojis with skin tone modifiers
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: jfx21
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2023-03-02
  • Updated: 2023-06-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8304041 - [WebView] Text on the left and right of emoji is not visible
Relates :  
JDK-8309565 - [Text] Enhance support for user-perceived characters (grapheme clusters)
Relates :  
JDK-8290866 - Apple Color Emoji turns gray after JavaFX version 18
Description
Prior to the emoji support for macOS added by JDK-8290866, some emojis didn't render at all on macOS. In at least one case, the reported spacing was correct even though nothing was drawn.

Now JavaFX renders the base emoji correctly, but if modifiers are added, it doesn't interpret the modifier as being part of the emoji, and both the spacing and rendering is wrong.

There is a failing WebKit DRT test -- LayoutTests/fast/text/emoji-with-joiner.html -- as a result (it was only accidentally passing before because the test was ignoring what was actually being rendered).

To reproduce this, run either the attach test program:

$ java EmojiTest

Or run HelloWebView with the attached html file:

$ java HelloWebView file:emoji-test.html

Both will render 3 sequences of emoji on three lines. The first is a sequence of identical code points of a face (female). This renders correctly via a Text node and WebView. The second is a sequence of emoji with different skin tones (still female), this does not render correctly and there is some extra spacing. The third is a sequence of emoji with a male modifier and different skin tones. It also does not render correctly and there is more extra spacing.

In addition to the programs, I have attached three images: the output of EmojiTest, the output of emoji-test.html run with HelloWebView, and the output of emoji-test.html run with Safari.
Comments
As noted, this isn't a bug, but is a lack of support for an optional feature. We should file an RFE to add support for emoji modifiers Once we understand why the WebKit case is different, we might close this bug as a duplicate of the yet-to-be-filed RFE.
02-03-2023
What is happening on the standalone EmojiTest is actually what you'd expect when seeing this sequence and not having the support and is actually per spec acc. to https://unicode.org/reports/tr51/#color as allowed fallback. The HTML example being different suggests that something in the webkit layer is interfering. Aside from that latter point, so far as I know, since there is no unicode code point for these combined glyphs, the only way to get to them is to invoke the complex text layout API when seeing a sequence with "exact patterns to be determined", and it then will do what it does when a ligature is requested .. because that's the only way I can see that a font could support this. TR 51 skips over how this would be implemented, but I don't see how else it can be done.
02-03-2023