Line breaks in notes

[flaviozluca]

Friend,

I found that notes, which I use a lot, have line feeds just fine in GO, but when I edit them in Officemail (old Rework/Nine), it adds breaks where they dont exist, making a mess. They say its something GO can improve to avoid it.
Details below.

Hi Flávio,
Thanks for the update — and yes, I can provide a clearer explanation you can forward to your server team.
What’s actually happening (why the extra line breaks appear)
OfficeMail Pro’s Notes are handled as plain text on the client side (we do not apply a full rich-text/HTML editor in Notes). In the previous investigation we confirmed the important point: after you save, the note content we receive back from the server already contains the line breaks. In other words, OfficeMail Pro is displaying the text payload returned by the server, not inserting formatting on its own.
In many third-party/compatibility servers, the Notes pipeline includes a conversion layer (e.g., plain text ↔ HTML, or internal “line wrapping” rules). That layer may:

convert a long single line into wrapped lines by inserting CR/LF, or
store notes in HTML/RTF and re-emit them in a way that changes line breaks.

That’s why it can look “clean” in webmail (some web UIs render whitespace differently), but when viewed or edited elsewhere the raw line breaks become visible.
Forwardable message to your server team
You can forward the below as-is:

OfficeMail Pro Notes are edited as plain text on the device (no full HTML/rich-text editor). When a note is saved, the client sends the updated content to the server, and then displays the content returned by the server on the next sync. We have observed that the “extra line breaks” are already present in the note text returned by the server, indicating that the server-side Notes storage/conversion layer is inserting line breaks (often due to line-length wrapping rules or HTML conversion). We cannot remove those breaks on the client without changing the server’s stored/returned text.

What to ask them to check

Confirm whether the server applies automatic line wrapping for Notes (e.g., a max line length rule).
Check how Notes are stored/returned (plain text vs HTML) and whether there’s a conversion step.
If possible, export the raw note content as stored on the server (source view) and verify whether CR/LF is already inserted before the mobile client displays it.

Workarounds (until the server behavior is corrected)

Keep long lines shorter (manual line breaks) to avoid triggering server wrapping rules.
If the server supports it, edit via the web UI that preserves the desired formatting and avoid re-saving from clients that receive “wrapped” text.

If your server team can share a sample of the raw note payload (or the server-side export showing the inserted CR/LF), we can also confirm exactly where the line breaks are being introduced.

Kind regards,
John Oh
Support Team

[mschering]

This is because GO stores it as html and when a client requests it as plain text it's converted to plain text. Can you give me some example note source html for testing?

[flaviozluca]

Hi, friend

Thanks for your reply. I simply write a note with some text, example

The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog.

I then save the note on my phone, via activesync.

It adds a break.

So it shows, for example, like this

The quick brown fox jumps
over the lazy dog. The quick brown fox jumps
over the lazy dog.

So you write any big sentence, then save it on your phone, when it syncs back, it adds breaks.