Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Also generate ligatures for RTL emoji sequences

See original GitHub issue

In https://github.com/googlefonts/nanoemoji/blob/main/src/nanoemoji/features.py, we only build GSUB ligatures for left-to-right (LTR) emoji sequences.

NotoColorEmoji.ttf also contains right-to-left (RTL) variants for those sequences that contain ZWJ (0x200D), see noto-emoji’s add_glyphs.py::get_rtl_seq method for how to get the correct RTL sequence from the LTR one (it’s not just reflect, the “Fitzpatrick modifiers” need to be treated specially): https://github.com/googlefonts/noto-emoji/blob/9a5261d871451f9b5183c93483cbd68ed916b1e9/add_glyphs.py#L227-L251

We should do the same here.

Issue Analytics

State:
Created 2 years ago
Comments:9 (5 by maintainers)

Top GitHub Comments

1reaction

behdadcommented, Dec 22, 2021

Earlier versions of HarfBuzz didn’t do anything special about emoji sequences. That meant that if these sequences appeared in out-of-context direction (eg. marked as Latin in right-to-left direction) then harfbuzz would flip them; that would make the GSUB rules not apply. Hence the reverse rules where added.

These days HB has special code to treat these sequences as atomic items, so when the buffer is being reversed they are reversed atomically. So that hack is not needed anymore.

0reactions

anthrotypecommented, Dec 22, 2021

Thanks Behdad. Then I think we can close the issue.