Regression on mac OS 12.3 build 21E230: Shaping of mixed skin tone handshakes

[drott]

Similar to issue #2967 we observe problems with Apple Color Emoji shaping again for mixed skin tone sequences:

With ToT HarfBuzz, built against chafa support:

Expected:

build/util/hb-shape --shaper=coretext /System/Library/Fonts/Apple\ Color\ Emoji.ttc --unicodes 1FAF1,1F3FF,200D,1FAF2,1F3FC,000A
[u1FAF1.5.L=0+0|u1FAF2.2.R=3+800]

Actual (built in shaper):

build/util/hb-shape /System/Library/Fonts/Apple\ Color\ Emoji.ttc --unicodes 1FAF1,1F3FF,200D,1FAF2,1F3FC,000A                  
[u1FAF1.5.L=0+800|space=0+0|u1FAF2.2.R=0+0]

More sequences that need checking:

build/util/hb-shape /System/Library/Fonts/Apple\ Color\ Emoji.ttc --unicodes 1F469,1F3FB,200D,1F91D,200D,1F469,1F3FC,1F9D1,1F3FE,200D,2764,200D,1F9D1,1F3FC,1FAF1,1F3FF,200D,1FAF2,1F3FC,1F9D1,1F3FC,200D,2764,200D,1F48B,200D,1F9D1,1F3FE 

I suspect Apple changed something in their font again in terms of how these emoji sequences are mapped to AAT shaping features.

In Chrome, this appears as the two "halves" of the emoji appearing spaced apart and interleaved with following characters, plus various selection issues, compare
https://bugs.chromium.org/p/chromium/issues/detail?id=1310282

@jfkthame @litherum

[drott]

Screenshot from Firefox, where this also fails:

[behdad]

Okay this was easy: the residual "DELETED" glyphs from morx processing were blocking GPOS MarkToBase attackment. Just deleting such glyphs before GPOS processing fixes the issue.

Should add test.

[drott]

Great, thanks, verified!