1463161 - emoji ligatures in Twemoji Mozilla font decompose when letter-spacing is applied

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect, P3)

Description

[Jonathan Kew [:jfkthame]]

On platforms where we use the Twemoji Mozilla font, ligatures such as Regional-Indicator flags or family groups will break if letter-spacing is applied.

data:text/html;charset=utf-8,<p style="letter-spacing:10px">%F0%9F%91%A8%E2%80%8D%F0%9F%91%A9%E2%80%8D%F0%9F%91%A7%F0%9F%91%A9%E2%80%8D%F0%9F%91%A7%E2%80%8D%F0%9F%91%A6</p>

This happens because the font uses the "liga" feature to ligate these sequences to single glyphs, but we automatically disable common ligatures when letter-spacing is used.

To fix this, we should modify the font to use the "ccmp" feature instead.

I've filed https://github.com/mozilla/twemoji-colr/pull/33 with a change to the font-generation script that I believe should resolve the problem; then we'll need to re-create the .ttf and import a new version into mozilla-central.

Comment 1

[Jonathan Kew [:jfkthame]]

smswessem, would you be interested in taking care of this? (After checking that my proposed change actually works as intended!)

Comment 2

[smswessem]

(In reply to Jonathan Kew (:jfkthame) from comment #1)
> smswessem, would you be interested in taking care of this? (After checking
> that my proposed change actually works as intended!)

Sure; I tested the changes and found that everything works as intended. Is it OK if I also update the Twemoji version and set the descent to 0 in the patch, as they perform better during testing?

Comment 3

[Jonathan Kew [:jfkthame]]

What difference does changing the descent make to how the font behaves in Firefox? (Could you provide a comparison screenshot, showing the effect that will have?)

Comment 4

[smswessem]

(In reply to Jonathan Kew (:jfkthame) from comment #3)
> What difference does changing the descent make to how the font behaves in
> Firefox? (Could you provide a comparison screenshot, showing the effect that
> will have?)

Well, I noticed while running the test suite that leaving the descent as the default setting gives 68 mismatches, while setting the descent to 0 gives 66. So we basically have a little bit more accuracy.

Comment 5

[Jonathan Kew [:jfkthame]]

OK, fewer mismatches sounds good. I'm more concerned, though, at whether changing the descent (to a rather non-typical value for fonts) might affect layout in the browser (interaction with line-height/vertical alignment of text).

Could you maybe create two .ttfs, one with the original metrics and one with the descent changed to zero, so we can try them in the browser and see if there's any effect on behavior that we need to consider? Thanks!

Comment 6

[smswessem]

Attachment: Font with descent set to 0

Comment 7

[smswessem]

Attachment: Font with default descent

Sure; I've attached the files.

Comment 8

[Jonathan Kew [:jfkthame]]

Sorry for the delay here. I tried building versions of Firefox with both the above fonts:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=dc62fb9d954e6243e7d994af42183919f74609d4 (attachment 8979765 [details])
https://treeherder.mozilla.org/#/jobs?repo=try&revision=1039cbb7e5c9547133be338255a753798c7eb6bf (attachment 8979766 [details])

The main difference I noted was that the second version gets an "unexpected pass" on 1463020-letter-spacing-text-transform-1, which is because it fixes this bug (so it's really a desired pass, and we need to update the test manifest), whereas the first one didn't pass that test -- apparently it doesn't include this bugfix. Is it possible you attached the wrong font file there?

The other thing I noted was that the font metrics (ascent/descent/linegap) in the two font files were actually identical. So again, I wondered if the wrong file got attached in comment 6?

In any case, at this point I'm more inclined to leave the metrics untouched; if it does appear that would be an improvement, we should do it separately in its own bug.

So... could you confirm if we should go ahead and create a patch to update to the font from comment 7, or does it need a further refresh for any reason? Thanks!

Comment 9

[Ian Moody [:Kwan] (UTC+0)]

Attachment: GitHub Pull Request