Emoji skin tone modifiers need to be treated as combining marks

[roozbehp]

With the way HarfBuzz handles direction in lookups, the emoji skin tone modifiers will not work in RTL text if they are implemented in GSUB (which is the only way I think they can be implemented).

Based on a conversation with Behdad, the only way to implement them right would be changing their general category to a combining mark. Since that's politically impossible at Unicode, the only out is overriding their behavior in HarfBuzz, similar to the way various Indic properties are overridden.

/cc @raphlinus @agustinfz @dougfelt

[KrasnayaPloshchad]

Maybe they can be joined via Combining Grapheme Joiner.

[khaledhosny]

I don’t see why it would not work as ligatures, sure enough I just built a test font and the ligatures do work in hb-view as well as Firefox. You can see the test here http://khaledhosny.org/files/tmp/test-emoji-color.html (the file http://khaledhosny.org/files/tmp/TestCLR-Regular2.ttf).

[roozbehp]

Khaled, would you please also attach a screenshot of what you're seeing on Firefox?

[behdad]

What I said was that these will not work if somehow they end up in an LTR run but marked as Arabic (or other RTL script). They work just fine most of the time.

[khaledhosny]

Here is how it looks for me in Firefox (the last line is RTL text):

[khaledhosny]

What I said was that these will not work if somehow they end up in an LTR run but marked as Arabic (or other RTL script). They work just fine most of the time.

Indeed:

hb-shape TestCLR-Regular.ttf a☺🏻a --script=arab --direction=ltr
[a=0+1024|smileface=1+1024|u1F3FB=2+1024|a=3+1024]

But I don’t see how this would happen under normal circumstances, someone using LRO inside an Arabic text? by why? I tried that in both Firefox an Chrome and the ligature is still formed. Interistingly, Chrome does not form the ligature in the LTR line (2nd line), is it related to this?

[khaledhosny]

I thought Chrome might not enabling the ligatures because the 2nd line goes through the fast path, but even with -webkit-font-feature-settings: "rlig" on; I still don’t get the ligature.

[behdad]

But I don’t see how this would happen under normal circumstances

Might happen around digits for example? Though, maybe not, since digits get their level bumped after all the neutrals are resolved. Yeah, I think I'm happy to accept that.

Roozbeh, let's think if we need this again. It looks to me like the things that can end up in an LTR run for RTL scripts is provably limited to digits and subtending marks. That is iff the script resolver takes cues from bidi levels. I find that a better solution to this problem.

[behdad]

This was easy enough to do with no significant extra cost on other text, so I went ahead and did it.

[behdad]

Roozbeh, let's think if we need this again. It looks to me like the things that can end up in an LTR run for RTL scripts is provably limited to digits and subtending marks. That is iff the script resolver takes cues from bidi levels. I find that a better solution to this problem.

Humm. Using LRE is legitimate supported use-case. So I take that back.

That said, the code I put into HarfBuzz in this issue is causing other problems, with ZWJ emoji sequences...