Am 31.01.2013 12:57, schrieb Thomas Bruederli:
Michael Heydekamp wrote:
For a number of good reasons, I usually do not produce messages in "format=flowed".
Roundcube (hopefully unintentional) seems to ignore my intention, as it does display EVERY message as it would be in "format=flowed" upon reading it. Specifically: Resizing the window also leads to a line-rewrapping, which is continously adapted to the current window size.
BTW: format=flowed just is a definition that says "don't break the lines as they are wrapped in the source". And this is what Roundcube does. Without format=flowed, the line breaks from the original source are kept and lines are wrapped as intended by the author.
Your scenario only is a problem when your browser window is smaller than to fit the 80 chars of the plain text body and this is very unlikely, even on 1024 screens.
I think you're chasing ghosts here.
Well, not exactly. A table/chart, ASCII-Art or something else can easily exceed those 80 chars and a lot more, especially when being quoted. By definition, upon transport a line can be 998 chars long (IIRC), and if the CTE is quoted-printable, it can even be endlessly long when being decoded and displayed.
Currently (and unfortunately) Roundcube can't produce non-flowed lines longer than specified in the config (76 chars in my case) - except when being quoted -, but other MUAs can. And they indeed do that!
As I said: Mails do not necessarily contain flowing text only.
So I don't know where this limit of 80 chars should be defined and coming from. Even our fully text-oriented MUA for DOS was/is able to intentionally produce much longer lines than 80 chars, although the screen size was of course limited to 80 chars.
Well, here's an example (as I said, I need to quote it, because otherwise Roundcube would line-wrap it upon sending):
+-----------+-----------+-----------+-----------+-----------+-----------+-----------+-----------+-----------+------------+ | Column #1 | Column #2 | Column #3 | Column #4 | Column #5 | Column #6 | Column #7 | Column #8 | Column #9 | Column #10 | +-----------+-----------+-----------+-----------+-----------+-----------+-----------+-----------+-----------+------------+ | Line #1 | Line #1 | Line #1 | Line #1 | Line #1 | Line #1 | Line #1 | Line #1 | Line #1 | Line #1 | +-----------+-----------+-----------+-----------+-----------+-----------+-----------+-----------+-----------+------------+
See...? I can also quote you some much more nicer (and wider) ASCII-Arts, if you want me to. ;)
May I request to limit this behaviour to messages which are explicitely declared as "format=flowed", but to avoid it for messages not being declared as such?
This is not that simple as I already explained to you.
I didn't state that it's simple. Just that it's possible. ;) But probably it's even simple, I don't know. I really hate to say that, but Squirrel doesn't do this unintentional line wrapping (that was the verification I mentioned in the quote below).
Many email systems produce messages without proper line breaks and without specifying format=flowed. I see mails (not sent from MUAs but other systems) which have long lines of text because lazy programmers don't understand how emails actually work.
Sure, but: Should Roundcube punish the sane MUAs and systems, and serve the insane systems instead?
Technically this is possible, as I just verified. ;)
Yes it is, but there are some reasons not to so. But we could start by adding some min-width: style to the message body to enforce a minimum width for the text contents. But I fear the side-effects of simply adding no-wrap for plain text parts without format=flowed.
Let me see if I can find out how Squirrel is avoiding it, gimme a sec....
No, sorry, I can't. Looking at the HTML source of the ugly Squirrel screenshot attached, I can find neither any no-wrap nor any min-width statement in the HTMl code. But these can be defined in some CSS declarations which I can't see, of course.
Interestingly, Squirrel is indeed wrapping the header, but not the body (as you can see). So there must be a way, this is all what I want to show.
I must admit that Squirrel behaves wrong in so far as it should even have line-wrapped the attached screenshot message. Because as a draft, Roundcube declares it as flowed by design, so it should be displayed as flowed. But this is exactly the contrary issue, and I'm not interested in fixing Squirrel issues...
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
