Support "Text as Bitmaps" from Gadgetbridge

[9cxndy]

Not sure if this is a Bangle.js exclusive feature. Like PineTime, Bangle.js doesn't support non-ASCII characters, but I can enable a "Text as Bitmaps" on Gadgetbridge, which will cause the text to be rendered on phone side and sent to the watch as bitmaps.

Can PineTime support the same?

There has been extensive requests for support of non-ASCII characters. I understand the developers chose to not include a more complete font because of resource constraints, but I think "text as bitmaps" could be a good compromise?

Related: #1490 #212 #1424 #1309 #261

[9cxndy]

Yes, this feature is bangle.js specific, but it doesn't look too difficult, and I think we can do better (and we have to since PineTime has less resources than Bangle). Bangle just renders the text and send it to the device uncompressed as a base64 string. Since PineTime is using lv_font_conv already, we can pre-build a compact bitmap cache on the phone and use that. I did some tests (based on Boteium/InfiniTime) and CJK characters can be pretty compact, at ~50 bytes/char (1 bpp, size 20).

[mark9064]

This sounds very interesting. I've been looking at font loading recently and it currently looks like #1773 is the most promising implementation (extra font packs). There's also the possibility of having a large font file with a custom loader (this will be less work than it sounds as I've already got a custom loader on the way (discussed in #2197)) - the practical limit here looks to be about 300 glyphs (without layers of on disk font indexes).

I guess you'd agree that font rendering is best done on device as it makes companion apps much simpler. But it looks like for the 10000s of CJK glyphs remote side rendering is the way. IMO this feature works with InfiniTime conceptually, but it involves a lot of moving parts: a new bluetooth protocol, new font loader/caching engine and of course companion app support. Basically my concern is that it's going to be complex and difficult to implement, and that it risks becoming a maintenance burden for both us and companion apps. But maybe it won't be so bad, what do you think?

[9cxndy]

I'd be very sad if i can't use pinetime for notifications because it's a very good watch. If there is a plan in the near future for some sort of pinetime 2 with a much bigger on-device storage that can do on-device rendering of cjk, then I would say don't bother. If not then IMHO this is something that has to be done.

you can have a look at bangle's implementation, idk how complex it is. but since there is already a watch doing this, then if we can have a (semi-)unified implementation, I feel it's probably not that bad for the gadgetbrige. I don't know about other companion apps.

new font loader/caching engine

i'd say forget about caching, just keep in memory the glyphs that are needed to show the current notifications.

[mark9064]

Sorry I wasn't clear, that's what I was trying to get at with "caching"- rather than streaming every glyph, the companion app sends the list of extra glyphs plus their code points needed for the message, so those glyphs must be cached in memory until the notification is cleared - no disk caching needed.

Definitely agree that re-using the existing infrastructure would make sense.

If someone implements this, I'll certainly review it!