Preamble:
This issue may get complicated. It's not a bug report, but at this stage just an appeal and attempt to understand the logic. Maybe Roundcube 1.0-git is doing it all correct, but maybe not.
The issue:
I received a message, produced with Roundcube 0.8.1, that contained the following quoted paragraph (without the dashed lines):
Mal was ganz anderes zwischendurch: Es ist ja jetzt bei der Telekom die Rede davon, zukünftig ab einer bestimmten Datenmenge den Durchsatz zu drosseln.
Three things are important to note upfront:
- The quote above is taken from the message source, not from the display
within Roundcube.
- Lines #1 and #3 of this quote have a trailing blank (20d) in the original
message (verified by saving it locally and looking at it with a hex editor). The message you are currently reading will not have these trailing blanks, as Roundcube 1.0-git does eliminate all trailing blanks prior to an EOL upon sending (no matter if the format is flowed or not). Which is a good idea, IMO, but apparently different to the behaviour of 0.8.1.
- The message is declared as charset=UTF-8, format=flowed and CTE 8bit (not
sure if this does play any role here).
The quote above is displayed in 1.0-git [GIT 20130503.1233] like this:
Mal was ganz anderes zwischendurch: Es ist ja jetzt bei der Telekom die Rede davon, zukünftig ab einer bestimmten Datenmenge den Durchsatz zu drosseln.
So the LF right after "zu " in Line #3 is being eliminated in the display, probably because of the trailing blank in line #3...?
But if that should be the reason, why then isn't the LF in line #1, right after "Telekom " being eliminated as well...?
So much to the display. Upon replying to this message, 1.0-git will will re-wrap the quoted paragraph like this (although I always trusted in that Roundcube wouldn't do any re-wrapping of quoted paragraphs):
Mal was ganz anderes zwischendurch: Es ist ja jetzt bei der Telekom die Rede davon, zukünftig ab einer bestimmten Datenmenge den Durchsatz zu drosseln.
Here, BOTH LFs in line #1 and #3 (with trailing blanks) are being eliminated, not only the one in line #3. So we have just two lines.
Which does of course look much more nice than the quote of the original message. But what is the logic behind this, and why is the display logic different to the reply/quote logic?
Furthermore, I'm not sure if re-wrapping of already quoted paragraphs is a good idea in all cases (in the case above it is, of course). If I think about plain text tables, ASCII art and such, this may become a mess (needs more testing).
Apparently the current behaviour is related to those trailing blanks right before EOL, and probably to format=flowed as well (not sure for the latter).
Any response welcome and appreciated.
P.S.: Sreenshots of display, editor quote and/or hex code of the original message can be sent, if so required.
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 05/08/2013 09:31 PM, Michael Heydekamp wrote:
Any response welcome and appreciated.
Looks like another issue. Fixed in git. I've found next issue, which is a designed behaviour (to prevent other issues), but doesn't look good to me now. When we reply to a format=flowed message with very long paragraphs the whole (quoted) paragraph is a one long line. This is not a big issue, the line is auto-wrapped in compose textarea element, but it might be annoying.
Am 09.05.2013 19:45, schrieb A.L.E.C:
On 05/08/2013 09:31 PM, Michael Heydekamp wrote:
Any response welcome and appreciated.
Looks like another issue. Fixed in git.
Saw the commit already, but didn't do a git-pull yet. Apparently only the display has been fixed, so the quoting is correct? Sure...?
Still not sure what the design/logic is. Currently 1.0-git does re-wrap quoted paragraphs (at least in particular cases), ist that by design? And in which cases does/should that happen?
I've found next issue, which is a designed behaviour (to prevent other issues), but doesn't look good to me now. When we reply to a format=flowed message with very long paragraphs the whole (quoted) paragraph is a one long line.
Right! And BTW: Is the blank at the end of line of any importance/meaning in quoted paragraphs?
Another question also is if there should be a difference in the design in these four scenarios:
- Original message non-flowed, reply non-flowed
- Original message flowed, reply non-flowed
- Original message non-flowed, reply flowed
- Original message flowed, reply flowed
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 05/09/2013 08:03 PM, Michael Heydekamp wrote:
Right! And BTW: Is the blank at the end of line of any importance/meaning in quoted paragraphs?
Yes, they are part of format=flowed standard. Space at end of line means "no real line break here".
Am 09.05.2013 20:08, schrieb A.L.E.C:
On 05/09/2013 08:03 PM, Michael Heydekamp wrote:
Right! And BTW: Is the blank at the end of line of any importance/meaning in quoted paragraphs?
Yes, they are part of format=flowed standard. Space at end of line means "no real line break here".
Ok, I wasn't sure if that applies to (the quote of already) quoted paragraphs as well.
But then we may have another issue in 1.0-git - as I wrote yesterday (related to quoted paragraphs only, of course):
The message you are currently reading will not have these trailing blanks, as Roundcube 1.0-git does eliminate all trailing blanks prior to an EOL upon sending (no matter if the format is flowed or not).
At least this is what I believe to have seen when I tested with format=flowed yesterday. If that is true, 1.0-git would break the flowed format - at least with quoted paragraphs.
Anyway, I'll test again and will report.
But which brings me back to my ancient request, that this setting (as well as the line length) should be user-configurable. It's a bit of an annoyance to always change the server-wide config just to run a flowed/non-flowed test. Plus that the user can't decide which format he wants to use and that he has to live with my personal preference (non-flowed). ;-)
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 09.05.2013 20:21, schrieb Michael Heydekamp:
Am 09.05.2013 20:08, schrieb A.L.E.C:
On 05/09/2013 08:03 PM, Michael Heydekamp wrote:
Right! And BTW: Is the blank at the end of line of any importance/meaning in quoted paragraphs?
Yes, they are part of format=flowed standard. Space at end of line means "no real line break here".
Ok, I wasn't sure if that applies to (the quote of already) quoted paragraphs as well.
But then we may have another issue in 1.0-git - as I wrote yesterday (related to quoted paragraphs only, of course):
The message you are currently reading will not have these trailing blanks, as Roundcube 1.0-git does eliminate all trailing blanks prior to an EOL upon sending (no matter if the format is flowed or not).
At least this is what I believe to have seen when I tested with format=flowed yesterday. If that is true, 1.0-git would break the flowed format - at least with quoted paragraphs.
Anyway, I'll test again and will report.
Well... We may (or may not) have another issue here. This was the original paragraph (taken from the source, the space is indicated with "[20d]" below):
Mal was ganz anderes zwischendurch: Es ist ja jetzt bei der Telekom[20d] die Rede davon, zukünftig ab einer bestimmten Datenmenge den Durchsatz zu[20d] drosseln.
Note that there is NO space after "Rede" in the second line. So upon replying, the paragraph will correctly be loaded in the plain text editor this way:
Mal was ganz anderes zwischendurch: Es ist ja jetzt bei der Telekom die Rede davon, zukünftig ab einer bestimmten Datenmenge den Durchsatz zu drosseln.
Note that there is still no space after "Rede", which is correct.
And it will be sent this way with format=flowed (again, space is indicated with "[20d]":
Mal was ganz anderes zwischendurch: Es ist ja jetzt bei der Telekom die[20d] Rede davon, zukünftig ab einer bestimmten Datenmenge den Durchsatz zu drosseln.
So all correct so far (although I don't know why "Rede" is wrapped to the second line, but due to the space at the end of the previous line, the format appears to be correct).
BUT:
If I deliberately ADD a space manually right after "Rede" this way in the editor, to deliberately make it a "full flowed" paragraph...
Mal was ganz anderes zwischendurch: Es ist ja jetzt bei der Telekom die Rede[20d] davon, zukünftig ab einer bestimmten Datenmenge den Durchsatz zu drosseln.
...THEN the [20d] right after "Rede" will be eliminated upon sending!?
Not sure if this is by design, but I wouldn't know why. If spaces at the end of a line do indeed apply to (the quote of) quoted paragraphs as well, then this appears to be an issue.
Tested with 8bit and qp, no difference.
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Sorry, but...
this format=flowed is killing me. Whenever I'm testing something, I'm running against another wall.
Look at my previous message: Some of the dashed lines above and below the quoted paragraphs do not start at the beginning of the line (as I entered them in the plain text editor), but three positions later. Screenshot attached.
First I thought the lines were indented, but then it appeared to me that the first three dashes have been replaced with spaces - either in the display or in the message source itself upon sending.
What I found:
- It happens only with format=flowed
- 8bit or qp don't make a difference
- line length MAY play a role, but I'm not sure
- The quote level needs to be > 1
Apart from the screenshot, the following files are attached:
- the original text as being entered in the editor (message.txt)
- the message sources as being sent in all variations (message [*].src) (just the relevant body part, without headers and signature)
The format of the flowed messages does look really strange, the qp versions even more than the 8bit versions. Even if this behaviour should be deliberate (which I honestly doubt), then the qp encoding does look insane to me. But that's again a different issue, then.
I wasn't able to dig any deeper, but I hope this analysis may help already.
And I'm wondering: Am I really the only one seeing those kind of things...? I mean, the most relevant task of any MUA is displaying, composing and replying to (= quoting) messages. ;-)
Usually, I'm not using format=flowed, now I'm even more convinced to stick to this position...
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 05/09/2013 11:26 PM, Michael Heydekamp wrote:
Sorry, but...
this format=flowed is killing me. Whenever I'm testing something, I'm running against another wall.
Sorry, I'll not read this, I'm also a little bit tired about this. Please, read http://www.ietf.org/rfc/rfc2646.txt.
Am 10.05.2013 08:08, schrieb A.L.E.C:
On 05/09/2013 11:26 PM, Michael Heydekamp wrote:
Sorry, but...
this format=flowed is killing me. Whenever I'm testing something, I'm running against another wall.
Sorry, I'll not read this, I'm also a little bit tired about this.
Well, then this format=flowed related bug will have to persist in Roundcube (unless Thomas would be willing to fix it). Even one more reason to disable it in the config, which is the default here anyway. I clearly stated that the issues I described do ONLY appear when format=flowed is enabled (in places where the format of the related paragraphs wasn't even flowed at all!).
I thought that Roundcube would have a pretense to do it right, if it is offering support of a feature (or in this context a format rather than a feature) at all. It would be absolutely fine for me to drop support for format=flowed (which is often also called "format=flawed") in Roundcube at all.
But supporting it and at the same time ignoring bugs, is, well, somewhat disappointing... Especially because I was just trying to help to improve Roundcube in an area which does neither affect myself nor our users, but most likely most of all other users, as format=flowed is even the default in the Roundcube config.
Sorry that you're tired about this, I can even understand it somehow (as the format is indeed flawed). But I did neither invent the format itself, nor it's support in Roundcube.
Please, read http://www.ietf.org/rfc/rfc2646.txt.
Apart from the fact that this document has absolutely nothing to do with the issues I posted: I can read it a hundred times a day: It won't fix the issues in Roundcube, and therefore Roundcube will still produce and display defective messages.
Too bad. :-(
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 05/10/2013 08:27 PM, Michael Heydekamp wrote:
Please, read http://www.ietf.org/rfc/rfc2646.txt.
Apart from the fact that this document has absolutely nothing to do with the issues I posted: I can read it a hundred times a day: It won't fix the issues in Roundcube, and therefore Roundcube will still produce and display defective messages.
I just think that reading and understanding it will make you asking less questions and understand possible issues (or not issues).
Am 10.05.2013 20:45, schrieb A.L.E.C:
On 05/10/2013 08:27 PM, Michael Heydekamp wrote:
Please, read http://www.ietf.org/rfc/rfc2646.txt.
Apart from the fact that this document has absolutely nothing to do with the issues I posted: I can read it a hundred times a day: It won't fix the issues in Roundcube, and therefore Roundcube will still produce and display defective messages.
I just think that reading and understanding it will make you asking less questions and understand possible issues (or not issues).
So you're saying that the issues I posted are no issues (although you didn't even read them)...??
Then you should read my post rather than saying "Sorry, I'll not read this". They are clear issues. But well, feel free to ignore them. Just too bad that I wasted time to analyze them and to attach screenshots and message text/sources.
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 05/10/2013 08:58 PM, Michael Heydekamp wrote:
So you're saying that the issues I posted are no issues (although you didn't even read them)...??
Then you should read my post rather than saying "Sorry, I'll not read this". They are clear issues. But well, feel free to ignore them. Just too bad that I wasted time to analyze them and to attach screenshots and message text/sources.
I'm just saying that I'm tired about explaining which are issues which are not, why there's a space at the end of line, etc. Also, I said that you should use bugtracker. Finally, don't post tons of issues in one go, even if related. Sorry, you don't pay me to spent a day on your posts, I've got better things to do. Didn't you observe that I'm the only one trying to follow your posts about text formatting? So, maybe it's not a high prio for others on this list too.
Am 11.05.2013 08:01, schrieb A.L.E.C:
On 05/10/2013 08:58 PM, Michael Heydekamp wrote:
So you're saying that the issues I posted are no issues (although you didn't even read them)...??
Then you should read my post rather than saying "Sorry, I'll not read this". They are clear issues. But well, feel free to ignore them. Just too bad that I wasted time to analyze them and to attach screenshots and message text/sources.
I'm just saying that I'm tired about explaining which are issues which are not, why there's a space at the end of line, etc.
I didn't ask any such kind of questions in my message which you meant to comment with "Sorry, I'll not read this". Far from it, I clearly stated that these ARE issues.
I also didn't ask why there are spaces at the EOL in one of my previous messages, as I'm very well aware of it. And because I'm very well aware of it, I just asked this:
Right! And BTW: Is the blank at the end of line of any importance/meaning in quoted paragraphs?
Would the meaning of spaces at EOL (in context with format=flowed) mean nothing to me, I wouldn't have raised this question, see...?
I just wasn't 100% sure if the same rule would apply to QUOTED paragraphs as well, as I do not know all RFCs by heart. So I thought it would be OK to ask you, as a person which I considered being more competent than me.
But apparently you feel offended by being asked a question. Although that was definitely not my intention, this is now well noted, though I don't understand it.
Also, I said that you should use bugtracker.
Sure. Nonetheless I believed that it's a rule to first post the issues here, and if they won't be fixed right away, a ticket shall be created. As you will remember, a number of issues had been fixed in the past (by you or by Thomas) which did never make their way to the bugtracker. Simply because the fix had been committed faster than I have been able to create a ticket.
If the current rule is that no issues at all shall be posted to this list anymore, then this rule is new to me. Please let me know if this rule does indeed apply.
Finally, don't post tons of issues in one go, even if related.
The message we are talking about is just about one single issue, not "tons of it".
Sorry, you don't pay me to spent a day on your posts, I've got better things to do.
Sorry, you don't pay me to test and analyze this stuff as well. (And I've got "better" things to do as well, but was just trying to help.)
My vision of the relation between testers and developers was a more cooperative one: Testers will find and report the issues as good and as analytic as they can, and the developers will hopefully fix them some day.
Years ago, when I was still developing our DOS/16 MUA, I ENCOURAGED users and testers to find and post issues, and was THANKFUL if they did that. I considered their work as valuable as the work of the developers. The more specific their reports were, the more valuable they were.
Didn't you observe that I'm the only one trying to follow your posts about text formatting? So, maybe it's not a high prio for others on this list too.
Maybe, maybe not. I'm often also not following up to other user's posts, but that doesn't mean that their posts are irrelevant to me (or, even more important, to Roundcube).
And, please: If text formatting (be it composing, quoting or forwarding) should not be considered as the most relevant basics that a MUA should handle correctly, then we are indeed in disagreement.
A final word to RFC2646, to which you pointed me at: This is obsoleted by RFC3676 in the meantime. But according to http://www.rfc-editor.org/info/rfc2646 and http://www.rfc-editor.org/info/rfc3676, both still have the status of a "PROPOSED STANDARD". But I'm of course aware that this status doesn't mean too much in real life.
All in all, I'm surprised and disappointed about your aggressive and unfriendly attitude. If you want me to stop testing, analyzing and posting issues to help to improve Roundcube, then, well, please just let me know.
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
-
A.L.E.C -
Michael Heydekamp