So I have joined a few mailing lists and it is necessary to write with a certain etiquette, this means I have to type with a message width of 72 columns.
This is fine on my desktop, where Thunderbird can autowrap and display messages properly due to the screen size. However K9 Mail’s wrapping makes it so linebreaks are still present when overwrapping, which makes the email annoying to read, I append a picture that can illustrate my problem.
Adding manual line breaks to keep lines under a certain length is bound to cause problems when there’s not enough display space to show that many characters in one line. The solution is really quite simple: don’t add manual line breaks for this; write long lines and let clients wrap the text however they see fit.
The maximum line length the internet message format allows is 998 characters. RFC 5322 contains this about the recommended line length of 78 characters:
The more conservative 78 character recommendation is to accommodate the many implementations of user interfaces that display these messages which may truncate, or disastrously wrap, the display of more than 78 characters per line, in spite of the fact that such implementations are non-conformant to the intent of this specification
But it’s 2021. No modern email client is displaying the raw message contents by default. Messages can contain long lines of text (even exceeding 998 characters) by using an encoding that will keep the encoded line length below an arbitrary value.
Available options are:
Content-Type: text/plain; charset=utf-8; format=flowed
I think that hard-wrapping email body at 78 characters is not a good#
idea, as it makes it harder for people to read your emails.
Line breaks preceded by a space (# in the example) are ignored when decoding the text.
Content-Transfer-Encoding, e.g. quoted-printable (this is what K-9 Mail uses)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
I think that hard-wrapping email body at 78 characters is not a good idea, =
as it makes it harder for people to read your emails.
Line breaks preceded by a = are ignored when decoding the text.
Both of these methods can keep the maximum (encoded) line length at e.g. 72 or 78 characters, but allow decoded text to have arbitrarily long lines. It’s then up to the client displaying the email to wrap the text to fit into the available screen space.
When emails use neither of these methods, but instead use “hard wraps” to satisfy an arbitrary maximum line length, clients have not much choice but to respect the line breaks (and most [including K-9 Mail] still wrap the text so it fits into the available space). This can lead to unfortunate situations like the one pictured in your screenshot.
See also this blog post: The problems with hard wrapping email body text.
If that’s the case, I have a problem to present you guys.
If I write a plain text email in Thunderbird and send it, it can be displayed correctly, both in Thunderbird and k9 mail.
If I forward the email, Thunderbird can forward it correctly and fine, still in plain text. However, K9 Mail seems to add hard line-breaks to the forwarded email (it doesn’t add linebreaks to the extra details I add)
This is the original email (seen from Thunderbird)
And this is how it displays when forwarded from K9-Mail
Now, when I originally write the email from Thunderbird I have it setup to be written as plain text, and it automatically gets wrapped, I assume it is according to the text=flowed standard, since there is a space after every word, just like the specs say.
None of these problems happen when I write a message in K9 and I forward it via k9, and it also does not happen when I write in TB and forward via TB. But since most emails I get are written from the desktop, and I fowared them from my phone, its fair to say this is a problem that needs to be addressed.
That’s a bug. See Replying to an email with format=flowed messes up the quoted text · Issue #3868 · k9mail/k-9 · GitHub
Thanks! I will take a look at that thread, glad it has been brought up before
Edit:
Yaay, thanks for working on this, I would mark this as solved as soon as it gets merged, but I dont think that’s possible since I didnt tag this as support lol
