-
Well, if Gadgetbridge sends UTF-8 - but I don't think it does so this still won't work without Gadgetbridge changes anyway.
Interesting - I expected it to do just that.
Have you seen E.decodeUTF8? It's built-in already and I feel like that should be faster and would avoid a bunch of code.
Wow, I completely missed it! This does exactly what I need. We could mention it in https://www.espruino.com/Fonts#character-sets -- I didn't expect that kind of function in
E.I'm afraid I prefer the Gadgetbridge option. If we do that, we can do exactly what you suggest with emoji, but it'll work for any emoji, or any language, without requiring any special uploads or setup. I feel like that's got to be a huge benefit.
Makes sense, yeah. I'm still worried about performance, but we could measure it and think of improvements afterwards. One possible way would be to implement some sort of on-device LRU cache for glyphs which is managed from Gadgetbridge side.
I'll see if I can make something work.
You are reading a single comment by @abbradar and its replies.
Click here to read the full conversation.
abbradar
Well, if Gadgetbridge sends UTF-8 - but I don't think it does so this still won't work without Gadgetbridge changes anyway.
Your approach would at least work well on iOS though where UTF8 is sent and we have no choice.
Yes, potentially we could.
Have you seen
E.decodeUTF8? It's built-in already and I feel like that should be faster and would avoid a bunch of code.I'm afraid I prefer the Gadgetbridge option. If we do that, we can do exactly what you suggest with emoji, but it'll work for any emoji, or any language, without requiring any special uploads or setup. I feel like that's got to be a huge benefit.
Your changes for the character map could be a good idea to pull in though (although it'd be nice to have some examples of what that mapping JSON file might look like)