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.
This breaks the display of things such as tables, charts, ASCII-Art etc., and makes them pretty unreadable. But exactly these things are the reason why I want to avoid "format=flowed". This format may make some sense if a message contains nothing but "flowing" text (but even then I find those extremely long lines difficult to read), but you can't take it for granted that a message does not contain anything else but "flowing" text.
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?
Technically this is possible, as I just verified. ;)
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 01/30/2013 12:05 AM, Michael Heydekamp wrote:
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.
Please, create a ticket and provide sample message which is wrongly displayed in Roundcube.
Am 30.01.2013 08:05, schrieb A.L.E.C:
On 01/30/2013 12:05 AM, Michael Heydekamp wrote:
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.
Please, create a ticket and provide sample message which is wrongly displayed in Roundcube.
Done, see http://trac.roundcube.net/ticket/1488937
But you can easily test this with EVERY format!=flowed message. Just resize the window.
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
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.
This breaks the display of things such as tables, charts, ASCII-Art etc., and makes them pretty unreadable. But exactly these things are the reason why I want to avoid "format=flowed". This format may make some sense if a message contains nothing but "flowing" text (but even then I find those extremely long lines difficult to read), but you can't take it for granted that a message does not contain anything else but "flowing" text.
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. 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. Forcing them to not being automatically wrapped by the browser would give you single-line messages with lots of horizontal scrolling.
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.
~Thomas
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
On 01/31/2013 09:27 PM, Michael Heydekamp wrote:
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!
You're mixing two things: displaying received messages and producing a message for sending. This is confusing.
Well, here's an example (as I said, I need to quote it, because otherwise Roundcube would line-wrap it upon sending):
+-----------+-----------+-----------+-----------+-----------+-----------+-----------+-----------+-----------+------------+
This line won't be wrapped because of no white spaces
| Column #1 | Column #2 | Column #3 | Column #4 | Column #5 | Column #6 | Column #7 | Column #8 | Column #9 | Column #10 |
and this will. So, maybe we could improve our wrapping code, so it will remember last line length (after wrapping) and will use the length for wrapping of current line. This at list should work for above use-case. Of course this will not work for any ASCII art.
This task is not simple because in plain text you cannot define which line should and which shouldn't be wrapped. Did you try to set line_length config option to some big value e.g. 200?
Am 01.02.2013 08:21, schrieb A.L.E.C:
On 01/31/2013 09:27 PM, Michael Heydekamp wrote:
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!
You're mixing two things: displaying received messages and producing a message for sending. This is confusing.
Right, sorry. The above was just meant as a remark, or call it a side-kick. I'm in this thread talking about displaying messages only. I may open another one for composing messages later on. (And I have a design for it, already, I just can't code it.)
+-----------+-----------+-----------+-----------+-----------+-----------+-----------+-----------+-----------+------------+
This line won't be wrapped because of no white spaces
Well, upon displaying it, it is being wrapped (I know that you're talking about composing here).
| Column #1 | Column #2 | Column #3 | Column #4 | Column #5 | Column #6 | Column #7 | Column #8 | Column #9 | Column #10 |
and this will. So, maybe we could improve our wrapping code, so it will remember last line length (after wrapping) and will use the length for wrapping of current line. This at list should work for above use-case. Of course this will not work for any ASCII art.
Right! And I wouldn't recommend to go this way (although I appreciate your approach).
But again, let's for the moment focus on displaying messages only, so that we indeed do not get confused.
And with regards to displaying messages, I can see just one correct way:
a) format=flowed: Do flow the display according to the window borders, no matter what.
b) format!=flowed: Do NOT flow the display according to the window borders, no matter what (even if the window might be resized to an absolute minimum).
It's all about the declaration in the CT header - would you agree?
This task is not simple because in plain text you cannot define which line should and which shouldn't be wrapped.
Well, you can (we did it in our DOS MUA). But this is - again - a different discussion, which I'm happy to continue later on.
Did you try to set line_length config option to some big value e.g. 200?
No, as this is not my intention. But let's forget about composing messages for the moment, ok?
But thanks for your comments anyway, I'm glad to see that you're thinking about it :)
-
A.L.E.C -
Michael Heydekamp -
Thomas Bruederli