A few missing glyphs in Apple Emoji Font

[ubitux]

The following glyphs are missing/misshaped when using Harfbuzz shaping on Apple Emoji Font.ttf: 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 44, 994, 996, 997, 998, 1000, 1001, 1003, 1005, 1006

Here is the glyph 1000 with Harfbuzz 2.0.2 on Linux:

% hb-shape 'Apple Color Emoji.ttf' '👨<200d>👩<200d>👧<200d>👦'
[u1F46A.0.MWG=0+800|space=0+0|u1F466.0=0+800]

Same one with Coretext shaping on Mac:

% hb-shape 'Apple Color Emoji.ttf' '👨<200d>👩<200d>👧<200d>👦'
[u1F46A.0.MWGB=0+800]

[behdad]

Thanks! Do you have a comprehensive list of the ligatures you can contribute for testing?

[behdad]

Humm. Works for me:
$ ./hb-shape 'AppleColorEmoji.ttf' --font-funcs=ot -u U+1F468,200d,U+1F469,200d,U+1F467,200d,U+1F466
[u1F46A.MWGB=0+800]

Can you double-check? Can you try with HarfBuzz master? Though, I don't remember changing anything regarding these. What's the font file size / checksum you have?

[ubitux]

% git describe
2.0.2-53-ge1b8e933
% util/hb-shape 'Apple Color Emoji.ttf' --font-funcs=ot -u U+1F468,200d,U+1F469,200d,U+1F467,200d,U+1F466
[u1F46A.0.MWG=0+800|space=0+0|u1F466.0=0+800]

The version of this font is pretty old though (but it's the same one I used to compare with harfbuzz Coretext shaping); it's 66M (69108708) with the following (sha256) checksum:

57651bd993f76edc7ce0db67c7b324fdb5a990b04860d7b24a7ed7e14a4c5849  Apple Color Emoji.ttf

Should I just share that file?

[behdad]

Thanks. Let me know if they are all fixed.

[ubitux]

The following are still not fixed: 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 44. They correspond to # 0 1 2 3 4 5 6 7 8 9 * followed by VS16.

This can be tested with the following: for c in $(python -c "print(' '.join('U+%04x,U+FE0F' % ord(x) for x in '#012345679*'))"); do hb-shape 'Apple Color Emoji.ttf' --font-funcs=ot -u $c; done

Without Coretext:

[numbersign=0+800|space=0+0]
[zero=0+800|space=0+0]
[one=0+800|space=0+0]
[two=0+800|space=0+0]
[three=0+800|space=0+0]
[four=0+800|space=0+0]
[five=0+800|space=0+0]
[six=0+800|space=0+0]
[seven=0+800|space=0+0]
[nine=0+800|space=0+0]
[asterisk=0+800|space=0+0]

With CoreText:

[numbersign=0+1600]
[zero=0+1600]
[one=0+1600]
[two=0+1600]
[three=0+1600]
[four=0+1600]
[five=0+1600]
[six=0+1600]
[seven=0+1600]
[nine=0+1600]
[asterisk=0+1600]

[behdad]

Are those same glyphs, or the glyphs have duplicate names? What's the output with --no-glyph-names?

[brawer]

Might be worth testing against all valid Emoji sequences?
https://unicode.org/emoji/charts/full-emoji-list.html
https://unicode.org/emoji/charts/full-emoji-modifiers.html
http://unicode.org/Public/emoji/11.0/

[ubitux]

Are those same glyphs, or the glyphs have duplicate names? What's the output with --no-glyph-names?

Without CoreText:

[4=0+800|3=0+0]
[5=0+800|3=0+0]
[6=0+800|3=0+0]
[7=0+800|3=0+0]
[8=0+800|3=0+0]
[9=0+800|3=0+0]
[10=0+800|3=0+0]
[11=0+800|3=0+0]
[12=0+800|3=0+0]
[14=0+800|3=0+0]
[44=0+800|3=0+0]

With Coretext:

[4=0+1600]
[5=0+1600]
[6=0+1600]
[7=0+1600]
[8=0+1600]
[9=0+1600]
[10=0+1600]
[11=0+1600]
[12=0+1600]
[14=0+1600]
[44=0+1600]

Removing the modifier gives the following in both cases:

[4=0+800]
[5=0+800]
[6=0+800]
[7=0+800]
[8=0+800]
[9=0+800]
[10=0+800]
[11=0+800]
[12=0+800]
[14=0+800]
[44=0+800]

[behdad]

Hah. So the actual glyph is the same. It's just spacing that differs?

[behdad]

That we leave a space glyph and CoreText does is expectd. The advance width difference isn't.

[behdad]

Humm. That font doesn't even have a kerx table. Something unusual is going on. I have no idea what.

[ebraminio]

i remember there was a lowdpi hidpi issue on Chrome on macOS pretty sinilar to what is described here happenning with Apple Emoji font, may the info will help.

[ebraminio]

If it is limited to some characters it may not related but still https://crbug.com/596223