Long notifications don't display properly

[Man-with-Arrow]

Notifications with more than a few words (i.e. over two lines) cut some words out, and don't display properly:

Using latest 1.1.0 (with added Hebrew fonts from this fork) and latest Gadgetbridge from F-Droid, on latest GrapheneOS (Pixel 4a).

[yehoshuapw]

This occurs regardless of the fork or main release.
Moreover, when disabling RTL support in Gadgetbridge, this does not happen. (in either case)
(the message "Long notifications clip and don't properly display" does however gets clipped at the final "l" also when disabled - again, regardless of the fork. EDIT: this too is gadgetbridge's debug send. in a normal notification this does not happen)

This is as expected - since the fork just adds fonts, it should not affect behavior.

In short, the issue is in Gadgetbridge and not here.

EDIT:
this seems to only happen when sending via the debug options of gadgetbridge.

[Man-with-Arrow]

I experienced this with notifications from Signal as well, as if the bottom-right portion of the display is hidden. I'll try and photograph when it happens, and update here.

[JF002]

Long notifications from gadgetbridge are displayed correctly on my side (release 1.1 without the hebrew fork and RTL language).
This issue is most probably caused by the fork or the companion app, but I'll wait for an update of @Man-with-Arrow to confirm it.

[Man-with-Arrow]

Long notifications from gadgetbridge are displayed correctly on my side (release 1.1 without the hebrew fork and RTL language).
This issue is most probably caused by the fork or the companion app, but I'll wait for an update of @Man-with-Arrow to confirm it.

Instead of littering this post with huge images, here's a .zip that should help explain the issue.

Now for some findings. I concur with @yehoshuapw, non-Gadgetbridge notifications in English come through just fine. With RTL enabled, English text looks a bit wonky (maybe Gadgetbridge sends a Unicode RLM, which results in an invisible first character?) but is still perfectly readable.

As for Hebrew, I found some strange behavior. Short messages (i.e. two lines and under) display just fine. Longer ones still display the first two lines fine, but start removing characters from the beginning and then end of the 3^rd line (i.e. if it were to remove just one, it would be the first character of the line). The 4^th line isn't even rendered. Messages that take up five lines or more simply don't appear on the Pinetime at all.

I'm hesitant to say if this is an issue with Gadgetbridge or Infinitime. Ideally, I'd test with a different companion app - but I'm not sure Amazfish even has RTL support.

I'll try to build Amazfish and run it on my PC, will update with results. In the meantime:

TL;DR: the fork is fine, wonky behavior is limited to Hebrew. Might be a Gadgetbridge issue, will test further and update.

[yehoshuapw]

I've just had a quick look at the BLE, and sending "הנה הודעה ארוכה בעברית, שתמלא חלק ניכר מהמסך הקטן של השעון."
With RTL enabled in GadgetBridge, and the line length set to 20 (via matrix.org).

We got:

we are missing some words here..

And what passed in BT was: (the ^ at the start, and $ at the end were added to show spaces)

^ הכורא העדוה הנה$
^ קלח אלמתש ,תירבעב$
^ לש ןטקה ךסמהמ רכינ$
^.ןועשה$

In short, the whole message was sent after all.
(and Gadgetbridge is not reversing the message itself? I was surprised enough that I triple checked that. It must be using LVGL's RTL somehow then.)

So it not Gadgetbridge. and without the RTL this does not happen - so perhaps LVGL's RTL has the bug.
Will take a closer look when I have more time.

debug_notifications.tar.gz

[jonvmey]

I think you might just be hitting the maximum notification message length in InfiniTime which is currently set to 100 bytes. Non-English text just shows issues related to that sooner due to using multiple bytes per character in UTF-8 (I'm assuming the text is UTF-8 encoded).

[JF002]

Indeed, in InfiniTime, there is a 100 bytes buffer for each notifications (I don't know if that limit changed in the Hebrew fork). The message will be truncated if it contains more bytes.

[Man-with-Arrow]

Great find! From what I've seen (and from #311) the only change is the added font, and mapping UTF characters to it. Now the question is, would increasing the 100-byte buffer be detrimental in any way?

[JF002]

Now the question is, would increasing the 100-byte buffer be detrimental in any way?

It depends on on much RAM memory is available. For now, there are 500 bytes (5 notifications * 100 bytes) allocated to notifications. You can of course increase the size of the buffer, but probably not that much, as RAM is almost completely filled. I'm doing so researches to find some ways to optimize RAM (and Flash) memory usage right now :)

[yehoshuapw]

Had another quick look.

Extending the size (moved the number of notifications down to 4, and removed the cyrillic symbols.) did allow some of the messages that didn't pass to pass fully. ("הנה הודעה ארוכה בעברית, שתמלא חלק ניכר מהמסך הקטן של השעון.")

Still some longer messages (after 88 chars, or 153 bytes) failed to display at all ("הודעה 9 בלה בלה בלה בלה בלה בלה בלה בלה בלה בלה בלה בלה בלה בלה בלה בלה בלה בלה בלה בלה") but did pass through the bluetooth (is there another buffer there, which must hold the whole thing?)

Gadgetbridge does reverse the things as expected - but both the terminal (which I knew) and the browser (which I didn't expect) reversed things again. (and while I verified using a line for each char, I seem to have got that wrong last time. So my comment in the parentheses was wrong.)

Anyways, while there may be another problem actually affecting Infinitime, this issue seems to be related to the fork (or to wider chars),
Therefore I think this issue should be closed - and continued discussion about this issue (and workarounds) may be done at the fork (so not to add spam here).

pinetime-mcuboot-app-dfu-1.1.0_4biggernotifications.zip
btsnoop_hci.txt

[jonvmey]

I suspect that the messages that fail to show at all might be related to the fact that InfiniTime isn't cutting the message off cleanly at a Unicode character boundary, it's just truncating to the maximum buffer size.

I haven't dug into the LVGL text handling code much but it's possible that if it receives an invalid UTF-8 string it just puts nothing on the screen.

An easy way to test this would be to take a long message that doesn't get displayed at all and add one single byte character (such as a space) to the beginning of it to see if that gives different results.

[ITCactus]

i am trying to extend support for couple of new languages in fonts, and on attempt to make the photo for PR just realized, that even with English characters sent from Gadgetbridge via "Debug" screen, long messages are truncated (and the strange thing that on the scrolling header there is a full-length message, while on the body the massage is truncated... but that's captured on the photo for this issue: "properly display" vs. "properly d"). for me, it's not a matter of RTL support - it is turned OFF in Gadgetbridge app.
the odd thing, is that for extra long messages (e.g. i tried to put all alphabet chars as a single message. 66 chars) Gadgetbridge (through Android SDK) can not write characteristic, and returns the error/status code "17" that is not documented by Android SDK.
e.g.
characteristic write: 00002a46-0000-1000-8000-00805f9b34fb (failed: 17)

is the code "17" coming from InfiniTime? @JF002 do you know or aware about it?

p.s. the version of the Gadgetbridge is the latest one from master (soon be released as 0.63.1), and the InfiniTime is from develop since 12 Dec (it was really tricky to make a build with DFU on windows with VS Code, even with Docker container - there are issues with EOL in "tools\mcuboot" py-scripts, and in 5 files EOL must be converted from Win to Linux format... not sure if it's container configuration issue, or it's a well-known one).

[Avamander]

@ITCactus

the odd thing, is that for extra long messages

0x11 is "Insufficient Resources". You ran into some limit, nothing odd about that really when you try something extra long.

that is not documented by Android SDK.

Those codes are not Android's, so it makes sense they aren't documented there.

i am trying to extend support for couple of new languages in fonts, and on attempt to make the photo for PR

Unlikely to be accepted unless it's dynamic glyph loading from flash.

[ITCactus]

@Avamander, thanks for clarification.

Unlikely to be accepted unless it's dynamic glyph loading from flash.

i tried to follow this readme to add support for 2 new languages by extending the "jetbrains_mono_bold_20.c" file (like it was done in PR #128).
is it acceptable/right way for that?

[Avamander]

@ITCactus

is it acceptable/right way for that?

Yes, but unlikely upstream. We're really storage-constrained and it's not a sustainable approach.

[yehoshuapw]

part of the issue here, is that sending long things from GadgetBridge's debug does not work.

that part of the issue is not here, but there.

Also, have a look at fork (branch hebrew-support) - And if you want, I can start making releases there also for another language.

(Long term, this is not a solution. but until fonts are moved and this is solved in a normal way, it works..)

[ITCactus]

@Avamander, i made a PR #887, and i would appreciate a feedback if it will NOT be accepted :)

@yehoshuapw, thanks, if it will NOT be accepted by InfiniTimeOrg, i'am OK to make a PR to your repo. of course, if you wish to have a support for proposed 2 new languages :)
otherwise, it can wait for a different way for support new languages by InfiniTime.

[yehoshuapw]

Notice #311
in some point someone (maybe me if I get around to it), will add loading fonts somehow from the storage, and then more can sit on the pinetime at once.

for now, adding more will not happen.

In my fork, I only do the releases, which are not that often - so I don't mind having another bit of stuff to do.
(I don't plan on having both fonts in at the same time, that's a waste of space. I'll have binaries for each)
Really, I'm just re-releasing with the added fonts. (and with an increased notification size)

[explit7]

The problem with long notifications are very annoying when using some apps e. g. (Online Banking), which sends SMS Tans. On Amazfit, i could look for the TAN and enter it in the banking app, now i need to switch between the sms app and banking app on my phone. Is there a possibility to add scrolling for long notifications ?

[yehoshuapw]

The problem with long notifications
unless you have characters which are not inside the ASCII (utf8 single byte really), then this doesn't seem to be your issue.

in the normal case, there's only 100 bytes per message, but parts of it are displayed (the start and end in some method).

[explit7]

In my case only the start is displayed, but the end of a message is more relevant, because it contains the TAN.

[JF002]

This is a known limitation : due to RAM limitation, InfiniTime can only store 5 notifications, and each notification has a buffer of 100 bytes for both the notification title and message. If the title is a 50 characters string, only the 1st 50 characters of the message will be displayed.
Also, some characters need more than 1 byte of storage (depending on the encoding, special characters,...), which might explain why the message sometimes appears truncated with less than 100 characters.

[Boteium]

Hypothetically, unused ascii control character can be repurposed to save space, right ? For example, we can made a special font with some control character replaced with Hebrew alphabet, and use GadgetBridge to transliterate Hebrew into control character.

Just a crazy idea