Emoji ZWJ Sequences are not grouped as single cluster

[drott]

Emoji ZWJ Sequences are not recognized/grouped into a single cluster when shaping them with a font that does not have glyphs for them. This makes emoji conflict with the shaper-driven segmentation approach we take in Chrome. If the page for example specifies Arial as a first font, the ZWJs get shaped with spaces, and the individual person emoji remain, which then get shaped with the fallback emoji font, but the run is already broken up by the zero width spaces taken from Arial, example:

$ ./hb-shape /Library/Fonts/Arial.ttf "👩‍👩‍👧‍👧 "
[.notdef=0+1536|space=1+0|.notdef=2+1536|space=3+0|.notdef=4+1536|space=5+0|.notdef=6+1536|space=7+569]

So here the Emoji glyphs are not found, but the ZWJs are shaped and rendered as zero width space glyphs from Arial.

At the moment, this could only be overriden in Blink by always explicitly prioritizing the system Emoji font over the fonts specified on the page for Emoji sequences.

Instead, however, I would propose to fix this by making them the same cluster and putting one .notdef for the whole emoji ZWJ sequence. Actually, probably similarly we need to think about the +Keycap and double-regional indicator sequences (as in Emoji flags).

Related to, but not duplicate of issue #179, I believe. CC @roozbehp

[behdad]

Keycap is already handled in cluster-level=0 (which I think Chrome uses). I don't mind adding flags and emoji...

[behdad]

On the other hand, most clients should be using cluster-level=1 and do their own Unicode grapheme boundaries for fallback anyway.

[khaledhosny]

Right which is sorta like what LibreOffice is doing, if a character is unsupported by the first font (0 GID) the whole Unicode grapheme cluster is reshaped, not just that character.

[drott]

Any new thoughts on this? Or is the right solution to use a different unit of fallback in Blink? (Edit:) It would be good if we could have HarfBuzz grouping them as a temporary solution before changing the fallback unit in Blink.

[behdad]

Because it's convenient, I'm going to combine ZWJ/ZWNJ with their previous cluster in cluster-level=0, as that's what the Unicode grapheme boundary algorithm does.
http://unicode.org/reports/tr29/

[roozbehp]

Behdad, UAX #29 is just about to change for ZWJ for Unicode 9 based on http://www.unicode.org/L2/L2016/16011r3-break-prop-emoji.pdf (which the UTC approved in their last meeting).

Also, I'm not sure I understand the exact change, but wouldn't this affect a sequence such as "Space, ZWJ, Arabic letter Ain"?

Reopening just in case.

[behdad]

Behdad, UAX #29 is just about to change for ZWJ for Unicode 9 based on http://www.unicode.org/L2/L2016/16011r3-break-prop-emoji.pdf (which the UTC approved in their last meeting).

Right. We can add more stuff here but prefer to keep it minimal.

Also, I'm not sure I understand the exact change, but wouldn't this affect a sequence such as "Space, ZWJ, Arabic letter Ain"?

Affects, yes. But it's no worse than before. If the layout system doesn't pass full context to HarfBuzz, then each ZWJ will end up in one run if the two sides are separated. Which one it will become part of is arbitrary. That said, I might do something smarter based on surroundings. But won't fix A,ZWJ,Ain.

Reopening just in case.

[behdad]

Closing for now. Will review additional cases separately.