Some emotes not changed with language pack

[hellcp]

I made a script for converting the emojis in this repo into a language pack in #3, and discovered that some ranges of emotes don't seem to be able to be covered by language files:

The following string looks like this on the watch:

"\U0000231A \U000026A7 \U00002705 \U00002728 \U0000274E \U00002757 \U00002763 \U00002B50 \U0001F31F \U0001F340 \U0001F3B6 \U0001F3F3 \U0001F4A5 \U0001F4AF \U0001F643 \U0001F644 \U0001F917 \U0001F918 \U0001F91D \U0001F923 \U0001F924 \U0001F929 \U0001F92A \U0001F970 \U0001F97A"

Would be good to investigate why that is.

[SteffanDonal]

Updating with some of my findings looking into this.

// Below not working, and return true for codepoint_is_emoji

// SYMBOLS_CODEPOINT
231A ⌚ https://www.fileformat.info/info/unicode/char/231A/index.htm
26A7 ⚧ https://www.fileformat.info/info/unicode/char/26A7/index.htm
2705 ✅ https://www.fileformat.info/info/unicode/char/2705/index.htm
2728 ✨ https://www.fileformat.info/info/unicode/char/2728/index.htm
274E ❎ https://www.fileformat.info/info/unicode/char/274E/index.htm
2757 ❗ https://www.fileformat.info/info/unicode/char/2757/index.htm
2763 ❣ https://www.fileformat.info/info/unicode/char/2763/index.htm
2B50 ⭐ https://www.fileformat.info/info/unicode/char/2B50/index.htm

// UNIFIED_EMOJI_CODEPOINT
1F31F 🌟 https://www.fileformat.info/info/unicode/char/1F31F/index.htm
1F340 🍀 https://www.fileformat.info/info/unicode/char/1F340/index.htm
1F3B6 🎶 https://www.fileformat.info/info/unicode/char/1F3B6/index.htm
1F3F3 🏳 https://www.fileformat.info/info/unicode/char/1F3F3/index.htm
1F4A5 💥 https://www.fileformat.info/info/unicode/char/1F4A5/index.htm
1F4AF 💯 https://www.fileformat.info/info/unicode/char/1F4AF/index.htm
1F643 🙃 https://www.fileformat.info/info/unicode/char/1F643/index.htm
1F644 🙄 https://www.fileformat.info/info/unicode/char/1F644/index.htm


// Below working, all return false for codepoint_is_emoji
// Note: "Supplemental Symbols and Pictographs" block, 1F900 to 1F9FF

1F917 🤗 https://www.fileformat.info/info/unicode/char/1F917/index.htm
1F918 🤘 https://www.fileformat.info/info/unicode/char/1F918/index.htm
1F91D 🤝 https://www.fileformat.info/info/unicode/char/1F91D/index.htm
1F923 🤣 https://www.fileformat.info/info/unicode/char/1F923/index.htm
1F924 🤤 https://www.fileformat.info/info/unicode/char/1F924/index.htm
1F929 🤩 https://www.fileformat.info/info/unicode/char/1F929/index.htm
1F92A 🤪 https://www.fileformat.info/info/unicode/char/1F92A/index.htm
1F970 🥰 https://www.fileformat.info/info/unicode/char/1F970/index.htm

// This fella does not work. Why?
1F97A 🥺 https://www.fileformat.info/info/unicode/char/1F97A/index.htm

This condition is responsible for the limitation:
https://github.com/pebble-dev/pebble-firmware/blob/main/src/fw/applib/graphics/text_resources.c#L566

Any glyphs that test false can be replaced by the extension resource pack:
https://github.com/pebble-dev/pebble-firmware/blob/main/src/fw/applib/graphics/text_resources.h#L139

Any glyphs that test true can only be loaded from the base font, and therefore, not replaceable.

This is something that could be fixed* in the new firmware but that's probably less desirable than just adding more emoji to the new base fonts.

*: Change the condition to accurately represent which emoji are actually included in the base fonts so we can extend them properly

---

The odd-one-out, 🥺, I can't find an explanation for. Tracing through the other functions for fail cases there are only a couple possible reasons:

• The font's offset table has a, or is causing a, bug resulting in an invalid (negative) data offset.
• sys_resource_load_range returned 0 while loading the glyph, meaning something went very wrong