Solved E-mail wrapping and modern clients

[kjpetrie]

It's a convention that a well-formatted e-mail should have its line length limited to 70 characters.

However, that was based on the width of what was once the standard 80-column VDU. Wrapping lines at 70 ensured correct display in such a terminal. Times have changed, and most people now view e-mail in clients or browsers with a different and unknown width and proportionally-spaced fonts of an unknown size.

The result is that an e-mail with a forced \r\n at every word break preceding 70 characters rarely displays neatly on a modern client and is apt to look like this:

Dear Mr Bloggs,

A Management Committee has been arranged with
voting to conclude at
5:0 on 1/3/2019. For further information or to cast
your votes please
see
https:/.....

which is either too narrow for the viewer's screen or too wide as above.

I wonder whether it's time to abandon the established "good practice" and allow clients to wrap text automatically.

What do people think?

 

[tommiie]

I have most of my applications full-screen, e.g. Firefox and Outlook run maximized. However, I still like to have my line width be a max of about 70 characters because that's easier to read. Letting text wrap automatically will create lines that are way too long to comfortably read.

That being said, I never manually format my emails to wrap at 70 characters. It's too much hassle in Outlook. Or better said: I'm too lazy to figure out whether or not this is possible and if so, how.

 

[getopt]

When console text meets mobile apps and vice versa ...
It's the responsibility of the makers of user interfaces to
take care about compatibility.

Perhaps the hybis of young app makers is a problem.

 

[ShelLuser]

Even though I recently started working with a 27" monitor (which is (was?) huge in my perception, having used 17" and 21" for most of my life) I still prefer to keep most of my program windowed in a smaller size. I hardly work with full screen, the only exceptions being Daz Studio, PowerPoint and some of my audio software (most notably Reason).

So for me the 70 character limitation still somewhat applies. Although I never bother when I write e-mails, I simply start writing and let ThunderBird handle it for me.

I have most of my applications full-screen, e.g. Firefox and Outlook run maximized.

Not my intention to derail the thread but I'm honestly curious: what Outlook version do you run?

 

[tommiie]

Not my intention to derail the thread but I'm honestly curious: what Outlook version do you run?

I run Outlook 2016 (Office365) at work. All my monitors are 20 (home) - 24 (work) inch or just the laptop monitor which is 17" I believe. I do want a bigger monitor but would prefer an app or something so that I can divide the monitor into different regions and maximize the app within that region. I often put two Firefox windows side-by-side as I find that easyer to work - shorter line widths...

 

[scottro]

A 70, or 72 character limit is still quite useful. If it goes full screen, it becomes difficult to read.
It's like a webpage. Do you want something spanning the full 20-30 inches of your monitor (whatever the actual width of the monitor is), or do you find it easier to read when it's been formatted to keep it a smaller width?

 

[kjpetrie]

My real concern is how it displays in a window/screen which is less than 70 characters wide, eg on a phone. I'm not worried about mails I send manually, it's the ones I send from my FreeBSD server in response to customers' activities there I'm thinking about. Should I use a wrapping function or not? If so, what should I wrap to, given I have no idea what the viewer's window and font sizes are?

I appreciate app-makers should respect standards, but if the device doesn't have a 70-column screen, how are they supposed to achieve that? Or are we really saying smart-phones shouldn't be allowed?

As for web pages, where possible I use columns. I believe a well-designed page will adjust to the available window and not try to force my choices on the viewer.

 

[xtaz]

Isn't this what format=flowed helps with? It causes the mail reader to join lines back together and display them nicely where appropriate. I certainly have that set with my own clients and never see emails broken at 70 chars.

 

[SR_Ind]

70 characters per line never is an issue.

All SMTP clients are expected to break long content at 70 character mark.

However, all POP3/IMAP4 clients are expected to reassemble the received content and then pass it on to the UI component for correct rendering.

I have Qt/C++ code doing that (sending/receiving). If someone is interested let me know.

 

[kpedersen]

However, all POP3/IMAP4 clients are expected to reassemble the received content and then pass it on to the UI component for correct rendering.

Really? So if I manually make sure to keep
to 70 characters a line, if they use outlook or
something else it will change them back to long
unbroken lines?

If you resize this window (or increase the font size), my nicely formatted text above will be broken into weird half cropped lines. I always worry about doing that at work because the "upper" management will think that I am being strange because they don't know... things .

When it comes to email, I honestly don't know what to do any more. I notice that most mainstream email clients (i.e Outlook Web) put things in this terrible TERRIBLE "conversation thread" mode which accounts for so many missed emails because it tucks them away into seemingly hidden dialogues.

 

[kjpetrie]

However, all POP3/IMAP4 clients are expected to reassemble the received content and then pass it on to the UI component for correct rendering.

Can you point to the RFC for that please, because I've never encountered a mail client which does?

If that were true I wouldn't be asking for advice. Nor am I seeking a client-side solution because I can't control recipients' systems. I'm trying to establish whether the conventional advice of wrapping text at 70 characters before sending is still appropriate for the environment people read in these days.

As for people who view the message full-screen or maximised, that's their choice. If they find it difficult to read like that they don't have to choose to read it like that. They can set a window size that suits them, so long as it's smaller than their screen. What they can't do is make the window bigger than their screen if there isn't enough room.

I want what I send out to be as accessible as possible to those who receive it, whatever they use to view it. I want to comply with the standard as well, but I'm trying to find out what the standard is for ensuring compatibility on width.

Update: Apparently, RFC 821/822 required the lines to be limited to 1,000 characters including the termination, so to be standards-compliant the wrap should be at 998 characters! So that's what the system requires and anything less is presumably just a cosmetic choice.

If that's right, I presume I have my answer.

 

[aragats]

Actually RFC 822 was superseded by RFC 2822, which still has both numbers: 998 and 78, see section 2.1.1. Line Length Limits:

There are two limits that this standard places on the number of
characters in a line. Each line of characters MUST be no more than
998 characters, and SHOULD be no more than 78 characters, excluding
the CRLF.

 

[kjpetrie]

Thank you. That's exactly the answer I need. RFC 2822 (dated 2001) gives the following explanation:

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 (and that of [RFC2821] if they actually cause
information to be lost). Again, even though this limitation is put on
messages, it is encumbant upon implementations which display messages
to handle an arbitrarily large number of characters in a line
(certainly at least up to the 998 character limit) for the sake of
robustness.

I think it's safe to assume that was a concession to the legacy 80-column screens which might still have been in occasional use in 2001, but would be extremely rare today. I think I should set the wrap to 998 as 70-78 is more trouble than it's worth nowadays. The balance behind the SHOULD has gone the other way in the intervening years. 18 years is a very long time in IT.