Besides some issues I'm still owing the creation of a ticket for, I just stumbled across another issue:
Apparently (and due to reasons which do escape me) Roundcube does delete leading blanks upon sending.
So if I compose (or forward) this...
AZERBAIJAN PERMIT AZA-0742/16.04.13 ENTRY/EXIT: ADEKI/DUKAN
UBBB HANDLING FCG/SW BUSINESS AVIATION COMPANY (22/23APR) PHONE: +994-xx-xxx-xxxx PAX HANDLING: SWBA GAT TERMINAL CREW TRANSFER CONFIRMED PAYMENT: ON CREDIT
UBBB HOTAC ROYAL PARK BAKU 4* (22/23APR) 2 SGL, RATE 86 EUR CNFM:52818SB000043/52818SB000044 PAYMENT BY C/C
TURKMENISTAN PERMIT GC/24/2047/080413 (UBBB-UTNU 23APR) EXIT: DUKAN / OTBOR
...it will be sent (and displayed at the recipient's end) like this:
AZERBAIJAN PERMIT AZA-0742/16.04.13 ENTRY/EXIT: ADEKI/DUKAN
UBBB HANDLING FCG/SW BUSINESS AVIATION COMPANY (22/23APR) PHONE: +994-xx-xxx-xxxx PAX HANDLING: SWBA GAT TERMINAL CREW TRANSFER CONFIRMED PAYMENT: ON CREDIT
UBBB HOTAC ROYAL PARK BAKU 4* (22/23APR) 2 SGL, RATE 86 EUR CNFM:52818SB000043/52818SB000044 PAYMENT BY C/C
TURKMENISTAN PERMIT GC/24/2047/080413 (UBBB-UTNU 23APR) EXIT: DUKAN / OTBOR
But that's not the way how I meant to send it. I'd like to send it "as is", which is "as composed" (WITH leading blanks).
Please note that I enclosed the text above in quote chars only to be able to illustrate the issue (as quoted lines keep being untouched by Roundcube upon sending). The original text did of course not have any leading quote chars.
I'm talking about plain text mails, qp-encoded.
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 04/20/2013 11:16 PM, Michael Heydekamp wrote:
Besides some issues I'm still owing the creation of a ticket for, I just stumbled across another issue:
Apparently (and due to reasons which do escape me) Roundcube does delete leading blanks upon sending.
Confirmed. There's still something wrong with rcube_mime::wordwrap(). Howeever, I wasn't able to fix it in a quick try. Please, create a ticket.
On 04/21/2013 10:53 AM, A.L.E.C wrote:
Confirmed.
Fixed. I completely rewritten wordwrap() method and added some more tests.
Am 21.04.2013 17:09, schrieb A.L.E.C:
Fixed.
You did fix it faster as I could create a ticket. :) Thanks a lot!
I completely rewritten wordwrap() method and added some more tests.
AFAIR there were some fixes in the last months, hopefully they didn't get lost. Plus there was still an issue I reported which I'm not sure if it had been fixed yet at all (see subject "Line wrapping f*cked up upon forwarding
- why?" in the RCD and RCU list).
But probably this issue disappeared automatically because of the rewrite.
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Hi Alec,
deletion of leading blanks seems indeed to be solved, but:
First issue encountered:
This is what I compose (without quote chars, of course):
SERVICE(S): What is requested Status
GEORGIA PERMIT 004/0025-13 ENTRY / EXIT: IDLER / ADEKI
Please note that there are just blanks between "GEORGIA" and "PERMIT" (no Tabs 09d or the like, but such scenarios still need to be tested as well).
This is being sent:
SERVICE(S): What is requested Status
GEORGIA PERMIT 004/0025-13 ENTRY / EXIT: IDLER / ADEKI
RC inserts an LF right after "GEORGIA".
Active settings in main.inc.php:
line_length = 76 send_format_flowed = false force_7bit = true (qp encoding)
I didn't test any other settings and/or scenarios yet. Think it makes more sense to wait for the next fix before going forward.
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 21.04.2013 17:57, schrieb Michael Heydekamp:
Am 21.04.2013 17:09, schrieb A.L.E.C:
Fixed.
You did fix it faster as I could create a ticket. :) Thanks a lot!
I completely rewritten wordwrap() method and added some more tests.
AFAIR there were some fixes in the last months, hopefully they didn't get lost. Plus there was still an issue I reported which I'm not sure if it had been fixed yet at all (see subject "Line wrapping f*cked up upon forwarding
- why?" in the RCD and RCU list).
But probably this issue disappeared automatically because of the rewrite.
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany _______________________________________________ Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev
On 04/21/2013 10:54 PM, Michael Heydekamp wrote:
SERVICE(S): What is requested Status
GEORGIA PERMIT 004/0025-13 ENTRY / EXIT: IDLER / ADEKI
Please note that there are just blanks between "GEORGIA" and "PERMIT" (no Tabs 09d or the like, but such scenarios still need to be tested as well).
This is being sent:
SERVICE(S): What is requested Status
GEORGIA PERMIT 004/0025-13 ENTRY / EXIT: IDLER / ADEKI
RC inserts an LF right after "GEORGIA".
Fixed. It looks that even the code from Zend Framework I used could not handle such case properly ;) We're going to have the best text wrapping method ever thanks to your "help" ;)
Am 22.04.2013 10:28, schrieb A.L.E.C:
On 04/21/2013 10:54 PM, Michael Heydekamp wrote:
SERVICE(S): What is requested Status
GEORGIA PERMIT 004/0025-13 ENTRY / EXIT: IDLER / ADEKI
Please note that there are just blanks between "GEORGIA" and "PERMIT" (no Tabs 09d or the like, but such scenarios still need to be tested as well).
This is being sent:
SERVICE(S): What is requested Status
GEORGIA PERMIT 004/0025-13 ENTRY / EXIT: IDLER / ADEKI
RC inserts an LF right after "GEORGIA".
Fixed. It looks that even the code from Zend Framework I used could not handle such case properly ;) We're going to have the best text wrapping method ever thanks to your "help" ;)
I can confirm, that:
- Leading blanks are not deleted anymore.
- The issue described above has been fixed.
- Another issue (most likely pretty much the same as 2) above) I
encountered today has been fixed as well:
I composed (without quote chars):
Test.
Best regards,
Michael Heydekamp
This has been sent this way:
Test.
Best regards, -- Michael Heydekamp
So an unintentional LF between "Best" and "regards". This is fixed as well now.
This "Zend Framework" looks somewhat insane to me. But may I ask: I didn't have all the issues above before (in 0.9), how and why did they make their way into 1.0-git? There were still some wordwrap issues in 0.9, yes, but not the ones we're currently talking about. So there must have been significant changes between 0.9 and 1.0 which did escape me.
I believe to have seen even more issues in the meantime, but I need to do more testing before I'll report them.
And with regards to the "help": Believe me, if I'd be capable of coding my own wordwrap(), I'd do it. But I'm not, so I can just report the issues I'm encountering.
To be continued...
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 22.04.2013 22:03, schrieb Michael Heydekamp:
To be continued...
This is about the difference between word/line wrapping upon forwarding and upon quoting a message.
Quoting works pretty well with Roundcube, the wrapping of the original message is being preserved (no ugly "Kammquoting", as we call it here, is being produced by Roundcube).
Different to forwarding a message:
If this is the original text (without quote chars)...
1234567890123456789012345678901234567890123456789012345678901234567890123456 Xxxxx http://xxxxx.xx.xx xxxxxx Xxx xxxx Xxxxxxxxxxxxx xxx xxx Xxxxxx xxx xxxxxxxx Xxxxxxx xxxxxxxxx. Xxxxx xxxxxx xxx xxxx xxxx xxxx Xxxxxxxxxxxxx, xxx xxx xxx Xxxxxxx xxx xxXXX, Xxxl5 xxx. xxxxxxxxx xxxx. Xxxxxxxxxxxxxxxxxx xxxx xxxx xxxxxxx, xxx Xxx xxx xxxxxxxxxxxxxx Xxxxxxx xxxxxx xxxxxx.
...then it is sent like this, when being forwarded "inline" (again, without quote chars, of course):
1234567890123456789012345678901234567890123456789012345678901234567890123456 Xxxxx http://xxxxx.xx.xx xxxxxx Xxx xxxx Xxxxxxxxxxxxx xxx xxx Xxxxxx xxx xxxxxxxx Xxxxxxx xxxxxxxxx. Xxxxx xxxxxx xxx xxxx xxxx xxxx Xxxxxxxxxxxxx, xxx xxx xxx Xxxxxxx xxx xxXXX, Xxxl5 xxx. xxxxxxxxx xxxx. Xxxxxxxxxxxxxxxxxx xxxx xxxx xxxxxxx, xxx Xxx xxx xxxxxxxxxxxxxx Xxxxxxx xxxxxx xxxxxx.
Look at the second and the third line. Of course, this is because of "line_length = 76" in main.inc.php. But this is an ugly line wrapping (and not the original one). This is issue #1.
Surprisingly, the third line of the original text is NOT being wrapped, although it should be according to the current logic - as it's 77 chars long (not counting the LF). Character counting seems to be incorrect, this is issue #2.
Anyway - now I'm wondering: Is there any logic to safely distinguish between "written" and "forwarded" text? And if not, shouldn't Roundcube simply precede forwarded text with quote chars (as it does when quoting the message) just to preserve the original word/line wrapping (and to prevent "Kammtext")?
I know, this is not a trivial issue. Just throwing in some thoughts and questions.
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 04/22/2013 11:23 PM, Michael Heydekamp wrote:
Anyway - now I'm wondering: Is there any logic to safely distinguish between "written" and "forwarded" text?
No.
And if not, shouldn't Roundcube simply precede forwarded text with quote chars (as it does when quoting the message) just to preserve the original word/line wrapping (and to prevent "Kammtext")?
No.
On 04/22/2013 10:03 PM, Michael Heydekamp wrote:
This "Zend Framework" looks somewhat insane to me. But may I ask: I didn't have all the issues above before (in 0.9), how and why did they make their way into 1.0-git? There were still some wordwrap issues in 0.9, yes, but not the ones we're currently talking about. So there must have been significant changes between 0.9 and 1.0 which did escape me.
Regressions just sometimes happen. Especially when there are no test cases created. Maybe you could take a look at our testing script and try to create more test-cases. The wordwrap-related are in https://github.com/roundcube/roundcubemail/blob/master/tests/Framework/Mime....
And with regards to the "help": Believe me, if I'd be capable of coding my own wordwrap(), I'd do it. But I'm not, so I can just report the issues I'm encountering.
No offense. There was an emoticon at the end of the sentence.
Am 23.04.2013 09:56, schrieb A.L.E.C:
On 04/22/2013 10:03 PM, Michael Heydekamp wrote:
This "Zend Framework" looks somewhat insane to me. But may I ask: I didn't have all the issues above before (in 0.9), how and why did they make their way into 1.0-git? There were still some wordwrap issues in 0.9, yes, but not the ones we're currently talking about. So there must have been significant changes between 0.9 and 1.0 which did escape me.
Regressions just sometimes happen.
Sure. But my impression is that in 1.0 a complete new word/line wrap routine has been implemented. Is this impression correct?
If so, this means that I have to start with all of my personal test cases from scratch.
Given the issues that I already encountered with the "real life" scenarios I've posted here, the new routine is looking worse than the one we've had before.
But anyway, I'm of course happy to help to improve this new routine as well. There may be scenarios which the new routine does handle better than the old one, probably I just haven't seen them yet.
Especially when there are no test cases created. Maybe you could take a look at our testing script and try to create more test-cases. The wordwrap-related are in https://github.com/roundcube/roundcubemail/blob/master/tests/Framework/Mime....
I'll post them here, whenever I'm running against a wall, please feel free to add them to this list.
I have posted another issue three days ago (with no response so far). See issue #2 in my message with the subject "Word/line wrapping of quoted and forwarded messages" of Apr 22nd, 23:23.
Although I'd like to avoid that inline-forwarded messages are being re-wrapped at all, I realize that this is not a trivial thing. But IF they are being rewrapped, the re-wrapping should be consistent. In the posted case it wasn't consistent.
And with regards to the "help": Believe me, if I'd be capable of coding my own wordwrap(), I'd do it. But I'm not, so I can just report the issues I'm encountering.
No offense. There was an emoticon at the end of the sentence.
I've seen that, and no offense was taken. I just wanted to stress that I'd be happy to contribute even more to improve the Roundcube code (rather than just posting issues), but I'm simply not capable to. Neither knowledge- nor time-wise.
Thanks for listening, thanks for Roundcube, and thanks to those who are developing it.
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 04/25/2013 09:21 PM, Michael Heydekamp wrote:
Regressions just sometimes happen.
Sure. But my impression is that in 1.0 a complete new word/line wrap routine has been implemented. Is this impression correct?
The same code is available in 0.9.
If so, this means that I have to start with all of my personal test cases from scratch.
Given the issues that I already encountered with the "real life" scenarios I've posted here, the new routine is looking worse than the one we've had before.
It passes all our tests including these added for issues described in this thread. So, I wouldn't say it's worse.
I have posted another issue three days ago (with no response so far). See issue #2 in my message with the subject "Word/line wrapping of quoted and forwarded messages" of Apr 22nd, 23:23.
I've said not once that we have bugtracker for issue requests.
Am 26.04.2013 09:58, schrieb A.L.E.C:
On 04/25/2013 09:21 PM, Michael Heydekamp wrote:
Regressions just sometimes happen.
Sure. But my impression is that in 1.0 a complete new word/line wrap routine has been implemented. Is this impression correct?
The same code is available in 0.9.
Because the new wrapping routine has been backported to 0.9...?
As long as I was using 0.9-git, I didn't have all those wrapping issues I described in my recent messages. Except a specific counting problem which I still need to test with the current routine.
I have posted another issue three days ago (with no response so far). See issue #2 in my message with the subject "Word/line wrapping of quoted and forwarded messages" of Apr 22nd, 23:23.
I've said not once that we have bugtracker for issue requests.
Issue #2 of this message wasn't a request but a bug which I thought you may want to add to your test cases. But surprisingly I can't replicate this bug anymore, so please forget about it.
Issue #1 of this message wasn't a request as well, but more an attempt to initiate a discussion about how forwarded messages should be wrapped (or how to avoid that they are being wrapped at all).
Comment to this issue would be most appreciated.
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 27.04.2013 22:02, schrieb Michael Heydekamp:
Am 26.04.2013 09:58, schrieb A.L.E.C: On 04/25/2013 09:21 PM, Michael Heydekamp wrote:
Regressions just sometimes happen.
Sure. But my impression is that in 1.0 a complete new word/line wrap routine has been implemented. Is this impression correct?
The same code is available in 0.9.
Because the new wrapping routine has been backported to 0.9...?
As long as I was using 0.9-git, I didn't have all those wrapping issues I described in my recent messages. Except a specific counting problem which I still need to test with the current routine.
This needs still to be tested.
But here's another surprising real life scenario which I encountered two days ago and which leads to an incorrect word/line wrapping with the current routine (occurring with the latest 1.0-git [GIT 20130502.2041).
We compose the following text:
(start)
Xxx xxxx xxxxxxxxxx xxxxx xx xxx xxxxxxx, xxxxxxxxx. Xxxx xxxx xxx xx xxxx xxxx xxxxxxxx Xxxxx xx xxx xxxxxxx Xxxx xxx xxx Xxxxxxx "xx Xxxx":
Xxxxx xxx xxx Xxxxxxx (Xxxx), xx xxxxx xxx xxxx xx xxx xxxxxxxx xxxxxxxx.
Xx, xxxx xxxxxxx: Xxx xxxxxx Xx xxxxxx?
Xxx, xxx xxxx xxx xxx xxxxxxx Xxxxx xx xxxxxxxxx, xx xxx xxxx xx xxxxxx xxxxx... Xxx Xxxxx, xxx xxx Xxxxxxxxxx Xxxxxx Xxxxx xxx 00.00. xxxxxxxx xxx, xxx xx xx Xxxxx xxxxxxxxxxxxxxxxx Xxxxxxxxx xxx Xxxxxxxx-Xxxxxx xxxxxx xxx (xxxxxx xxxxxxx xx xxxxxx Xxxx xxx 00.00., 00:00 Xxx, Xxxxxxx "Xxxxxxxxxx xxxxxx"), xxx Xx xx xxxxxx Xxxxxxxxx xxx Xxxxxxxxxx Xxxxxx Xxxxxxx xxxxxx (Xxxx xxx 00.00., 00:00 Xxx), xx Xxx xxx xxxxxxxx Xxxx xxx xxxxxxxxxxxx xxxxx (Xxxx xxx 00.00., 00:00 Xxx), xxx:
Xxxx,
(end)
Remember, the active settings in main.inc.php are:
line_length = 76 send_format_flowed = false force_7bit = true (qp encoding)
The x-ed text above will be word/line wrapped this way:
(start)
Xxx xxxx xxxxxxxxxx xxxxx xx xxx xxxxxxx, xxxxxxxxx. Xxxx xxxx xxx xx xxxx xxxx xxxxxxxx Xxxxx xx xxx xxxxxxx Xxxx xxx xxx Xxxxxxx "xx Xxxx":
Xxxxx xxx xxx Xxxxxxx (Xxxx), xx xxxxx xxx xxxx xx xxx xxxxxxxx xxxxxxxx.
Xx, xxxx xxxxxxx: Xxx xxxxxx Xx xxxxxx?
Xxx, xxx xxxx xxx xxx xxxxxxx Xxxxx xx xxxxxxxxx, xx xxx xxxx xx xxxxxx xxxxx... Xxx Xxxxx, xxx xxx Xxxxxxxxxx Xxxxxx Xxxxx xxx 00.00. xxxxxxxx xxx, xxx xx xx Xxxxx xxxxxxxxxxxxxxxxx Xxxxxxxxx xxx Xxxxxxxx-Xxxxxx xxxxxx xxx (xxxxxx xxxxxxx xx xxxxxx Xxxx xxx 00.00., 00:00 Xxx, Xxxxxxx "Xxxxxxxxxx xxxxxx"), xxx Xx xx xxxxxx Xxxxxxxxx xxx Xxxxxxxxxx Xxxxxx Xxxxxxx xxxxxx (Xxxx xxx 00.00., 00:00 Xxx), xx Xxx xxx xxxxxxxx Xxxx xxx xxxxxxxxxxxx xxxxx (Xxxx xxx 00.00., 00:00 Xxx), xxx:
Xxxx,
(end)
The first paragraph is being wrapped correctly and according to the settings in main.inc.php. The second paragraph and the dashed lines enclosing it won't be touched anyway, the third paragraph is too short for any wrapping, BUT:
The fourth paragraph is - in contradiction to the settings in main.inc.php - not being wrapped at all. It will be sent in the same way as if "send_format_flowed = true" would be the active setting in main.inc.php. But that's not the case (although it's the case in THIS message, otherwise I wouldn't be able to demonstrate the issue).
After some investigation, I found out that the dashed lines which enclose the quoted paragraph, seem to be the cause of the issue. They are 77 chars long, but as there is no blank, they can't and won't of course be wrapped.
But if I reduce the length of these dashed lines to say 73 (i.e. less than 76) chars, then the fourth paragraph will be correctly word/line wrapped this way:
Xxx, xxx xxxx xxx xxx xxxxxxx Xxxxx xx xxxxxxxxx, xx xxx xxxx xx xxxxxx xxxxx... Xxx Xxxxx, xxx xxx Xxxxxxxxxx Xxxxxx Xxxxx xxx 00.00. xxxxxxxx xxx, xxx xx xx Xxxxx xxxxxxxxxxxxxxxxx Xxxxxxxxx xxx Xxxxxxxx-Xxxxxx xxxxxx xxx (xxxxxx xxxxxxx xx xxxxxx Xxxx xxx 00.00., 00:00 Xxx, Xxxxxxx "Xxxxxxxxxx xxxxxx"), xxx Xx xx xxxxxx Xxxxxxxxx xxx Xxxxxxxxxx Xxxxxx Xxxxxxx xxxxxx (Xxxx xxx 00.00., 00:00 Xxx), xx Xxx xxx xxxxxxxx Xxxx xxx xxxxxxxxxxxx xxxxx (Xxxx xxx 00.00., 00:00 Xxx), xxx:
So, apparently the (first?) occurence of an unwrappable line longer than the max. length defined in main.inc.php disables the word/line wrapping for the entire rest of the message content?? Or has it to do with the dashes...? Or both...?
This issue is in so far different and even contradictious to the ones that I posted before, as there LFs had been inserted where they shouldn't have been inserted (and dashed lines played a role there as well, AFAICS). In the case above it's the opposite: LFs are NOT inserted, although they should have been inserted.
Anyway, please add this to your test cases. And a fix would be highly appreciated, of course.
And believe me: I'm not desperately searchig for those kind of issues, they just happen to me in my daily Roundcube life.
Ah, and well: Can we please finally make the settings...
line_length = 76 send_format_flowed = false force_7bit = true (qp encoding)
...user-configurable?
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Reading my own message that I just sent to this list and which is quoted below, I couldn't trust my eyes: The different quote levels have been reduced to just one and the same quote level, so it reads as if the entire quoted text would have been written by me. To illustrate - rather than...
(start)
Regressions just sometimes happen.
Sure. But my impression is that in 1.0 a complete new word/line wrap routine has been implemented. Is this impression correct?
The same code is available in 0.9.
Because the new wrapping routine has been backported to 0.9...?
As long as I was using 0.9-git, I didn't have all those wrapping issues I described in my recent messages. Except a specific counting problem which I still need to test with the current routine.
(end, note that these are four different quote levels!)
...it's now looking this way:
(start)
Regressions just sometimes happen.
Sure. But my impression is that in 1.0 a complete new word/line wrap routine has been implemented. Is this impression correct?
The same code is available in 0.9.
Because the new wrapping routine has been backported to 0.9...?
As long as I was using 0.9-git, I didn't have all those wrapping issues I described in my recent messages. Except a specific counting problem which I still need to test with the current routine.
(end)
(BTW: I'm using these "(start)" and "(end)" indicators, as dashed lines may currently cause problems, see my previous message.)
This is how to replicate the quote level issue:
- Reply to my message of April 27th, 22:02 local time.
- Save it as a draft.
- Click on the "Cancel" button.
- Go to the Drafts folder and view the message.
- All different quote levels have been reduced to just one.
I'm not even sure if I can now send THIS message without losing the quote levels again, as this message has been saved during composing as a draft as well (and just looking at the draft in a separate window, the different quote levels are indeed gone again).
Hmm... Probably I should paste this message to the clipboard, compose it again and click on the "Send now" button before Roundcube does even have the chance to save it as a draft? Yeah, I'm gonna try that.
But strange this, uh....? Is this another result of the new wrapping routine, or something else? I'm using [GIT 20130502.2041].
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 02.05.2013 22:09, schrieb Michael Heydekamp:
Am 27.04.2013 22:02, schrieb Michael Heydekamp:
Am 26.04.2013 09:58, schrieb A.L.E.C: On 04/25/2013 09:21 PM, Michael Heydekamp wrote:
Regressions just sometimes happen.
Sure. But my impression is that in 1.0 a complete new word/line wrap routine has been implemented. Is this impression correct?
The same code is available in 0.9.
Because the new wrapping routine has been backported to 0.9...?
As long as I was using 0.9-git, I didn't have all those wrapping issues I described in my recent messages. Except a specific counting problem which I still need to test with the current routine.
This needs still to be tested.
But here's another surprising real life scenario which I encountered two days ago and which leads to an incorrect word/line wrapping with the current routine (occurring with the latest 1.0-git [GIT 20130502.2041).
We compose the following text:
(start)
Xxx xxxx xxxxxxxxxx xxxxx xx xxx xxxxxxx, xxxxxxxxx. Xxxx xxxx xxx xx xxxx xxxx xxxxxxxx Xxxxx xx xxx xxxxxxx Xxxx xxx xxx Xxxxxxx "xx Xxxx":
Xxxxx xxx xxx Xxxxxxx (Xxxx), xx xxxxx xxx xxxx xx xxx xxxxxxxx xxxxxxxx.
Xx, xxxx xxxxxxx: Xxx xxxxxx Xx xxxxxx?
Xxx, xxx xxxx xxx xxx xxxxxxx Xxxxx xx xxxxxxxxx, xx xxx xxxx xx xxxxxx xxxxx... Xxx Xxxxx, xxx xxx Xxxxxxxxxx Xxxxxx Xxxxx xxx 00.00. xxxxxxxx xxx, xxx xx xx Xxxxx xxxxxxxxxxxxxxxxx Xxxxxxxxx xxx Xxxxxxxx-Xxxxxx xxxxxx xxx (xxxxxx xxxxxxx xx xxxxxx Xxxx xxx 00.00., 00:00 Xxx, Xxxxxxx "Xxxxxxxxxx xxxxxx"), xxx Xx xx xxxxxx Xxxxxxxxx xxx Xxxxxxxxxx Xxxxxx Xxxxxxx xxxxxx (Xxxx xxx 00.00., 00:00 Xxx), xx Xxx xxx xxxxxxxx Xxxx xxx xxxxxxxxxxxx xxxxx (Xxxx xxx 00.00., 00:00 Xxx), xxx:
Xxxx,
(end)
Remember, the active settings in main.inc.php are:
line_length = 76 send_format_flowed = false force_7bit = true (qp encoding)
The x-ed text above will be word/line wrapped this way:
(start)
Xxx xxxx xxxxxxxxxx xxxxx xx xxx xxxxxxx, xxxxxxxxx. Xxxx xxxx xxx xx xxxx xxxx xxxxxxxx Xxxxx xx xxx xxxxxxx Xxxx xxx xxx Xxxxxxx "xx Xxxx":
Xxxxx xxx xxx Xxxxxxx (Xxxx), xx xxxxx xxx xxxx xx xxx xxxxxxxx xxxxxxxx.
Xx, xxxx xxxxxxx: Xxx xxxxxx Xx xxxxxx?
Xxx, xxx xxxx xxx xxx xxxxxxx Xxxxx xx xxxxxxxxx, xx xxx xxxx xx xxxxxx xxxxx... Xxx Xxxxx, xxx xxx Xxxxxxxxxx Xxxxxx Xxxxx xxx 00.00. xxxxxxxx xxx, xxx xx xx Xxxxx xxxxxxxxxxxxxxxxx Xxxxxxxxx xxx Xxxxxxxx-Xxxxxx xxxxxx xxx (xxxxxx xxxxxxx xx xxxxxx Xxxx xxx 00.00., 00:00 Xxx, Xxxxxxx "Xxxxxxxxxx xxxxxx"), xxx Xx xx xxxxxx Xxxxxxxxx xxx Xxxxxxxxxx Xxxxxx Xxxxxxx xxxxxx (Xxxx xxx 00.00., 00:00 Xxx), xx Xxx xxx xxxxxxxx Xxxx xxx xxxxxxxxxxxx xxxxx (Xxxx xxx 00.00., 00:00 Xxx), xxx:
Xxxx,
(end)
The first paragraph is being wrapped correctly and according to the settings in main.inc.php. The second paragraph and the dashed lines enclosing it won't be touched anyway, the third paragraph is too short for any wrapping, BUT:
The fourth paragraph is - in contradiction to the settings in main.inc.php
- not being wrapped at all. It will be sent in the same way as if
"send_format_flowed = true" would be the active setting in main.inc.php. But that's not the case (although it's the case in THIS message, otherwise I wouldn't be able to demonstrate the issue).
After some investigation, I found out that the dashed lines which enclose the quoted paragraph, seem to be the cause of the issue. They are 77 chars long, but as there is no blank, they can't and won't of course be wrapped.
But if I reduce the length of these dashed lines to say 73 (i.e. less than 76) chars, then the fourth paragraph will be correctly word/line wrapped this way:
Xxx, xxx xxxx xxx xxx xxxxxxx Xxxxx xx xxxxxxxxx, xx xxx xxxx xx xxxxxx xxxxx... Xxx Xxxxx, xxx xxx Xxxxxxxxxx Xxxxxx Xxxxx xxx 00.00. xxxxxxxx xxx, xxx xx xx Xxxxx xxxxxxxxxxxxxxxxx Xxxxxxxxx xxx Xxxxxxxx-Xxxxxx xxxxxx xxx (xxxxxx xxxxxxx xx xxxxxx Xxxx xxx 00.00., 00:00 Xxx, Xxxxxxx "Xxxxxxxxxx xxxxxx"), xxx Xx xx xxxxxx Xxxxxxxxx xxx Xxxxxxxxxx Xxxxxx Xxxxxxx xxxxxx (Xxxx xxx 00.00., 00:00 Xxx), xx Xxx xxx xxxxxxxx Xxxx xxx xxxxxxxxxxxx xxxxx (Xxxx xxx 00.00., 00:00 Xxx), xxx:
So, apparently the (first?) occurence of an unwrappable line longer than the max. length defined in main.inc.php disables the word/line wrapping for the entire rest of the message content?? Or has it to do with the dashes...? Or both...?
This issue is in so far different and even contradictious to the ones that I posted before, as there LFs had been inserted where they shouldn't have been inserted (and dashed lines played a role there as well, AFAICS). In the case above it's the opposite: LFs are NOT inserted, although they should have been inserted.
Anyway, please add this to your test cases. And a fix would be highly appreciated, of course.
And believe me: I'm not desperately searchig for those kind of issues, they just happen to me in my daily Roundcube life.
Ah, and well: Can we please finally make the settings...
line_length = 76 send_format_flowed = false force_7bit = true (qp encoding)
...user-configurable?
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany _______________________________________________ Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev
Am 02.05.2013 23:18, schrieb Michael Heydekamp:
I'm not even sure if I can now send THIS message without losing the quote levels again, as this message has been saved during composing as a draft as well (and just looking at the draft in a separate window, the different quote levels are indeed gone again).
Hmm... Probably I should paste this message to the clipboard, compose it again and click on the "Send now" button before Roundcube does even have the chance to save it as a draft? Yeah, I'm gonna try that.
That did the trick! (But that's not a solution, of course.)
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 05/02/2013 11:18 PM, Michael Heydekamp wrote:
- Reply to my message of April 27th, 22:02 local time.
- Save it as a draft.
- Click on the "Cancel" button.
- Go to the Drafts folder and view the message.
- All different quote levels have been reduced to just one.
I'm not even sure if I can now send THIS message without losing the quote levels again, as this message has been saved during composing as a draft as well (and just looking at the draft in a separate window, the different quote levels are indeed gone again).
But strange this, uh....? Is this another result of the new wrapping routine, or something else? I'm using [GIT 20130502.2041].
Both issues has been fixed in git.
Am 03.05.2013 09:29, schrieb A.L.E.C:
On 05/02/2013 11:18 PM, Michael Heydekamp wrote:
- Reply to my message of April 27th, 22:02 local time.
- Save it as a draft.
- Click on the "Cancel" button.
- Go to the Drafts folder and view the message.
- All different quote levels have been reduced to just one.
I'm not even sure if I can now send THIS message without losing the quote levels again, as this message has been saved during composing as a draft as well (and just looking at the draft in a separate window, the different quote levels are indeed gone again).
But strange this, uh....? Is this another result of the new wrapping routine, or something else? I'm using [GIT 20130502.2041].
Both issues has been fixed in git.
Not sure which "both issues" you mean, but I can confirm that the quote level issue appears to be fixed (1.0-git [GIT 20130503.1233]).
Thanks!
Being curious: How did this bug make it's way into Roundcube? I mean, it did work before, so why should there be any change...?
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 05/03/2013 08:56 PM, Michael Heydekamp wrote:
Both issues has been fixed in git.
Not sure which "both issues" you mean, but I can confirm that the quote level issue appears to be fixed (1.0-git [GIT 20130503.1233]).
I meaned the wrapping issue is fixed too.
Thanks!
Being curious: How did this bug make it's way into Roundcube? I mean, it did work before, so why should there be any change...?
I don't remember, but it was my mistake in code changes for some bugfix or improvement. Because there was no test script for such case we didn't observe this regression then. As stated before, regressions happen when there's not enough test-case scripts.
Am 04.05.2013 08:49, schrieb A.L.E.C:
On 05/03/2013 08:56 PM, Michael Heydekamp wrote:
Both issues has been fixed in git.
Not sure which "both issues" you mean, but I can confirm that the quote level issue appears to be fixed (1.0-git [GIT 20130503.1233]).
I meaned the wrapping issue is fixed too.
The one with the dashed lines > 76 chars? Hold on...
Yep, this appears to be fixed as well, thanks a lot.
May I ask: What was the cause? That there was a line longer than 76 chars without any whitespace, or that there was a DASHED line longer than 76 chars without any whitespace?
My impression was/is that especially dashed lines have been causing some issues with this new wrapping routine, but in this particular case I'm not sure.
And I'd like to know that, as I would then know where I would have to keep an eye on.
[lost quote levels]
Being curious: How did this bug make it's way into Roundcube? I mean, it did work before, so why should there be any change...?
I don't remember, but it was my mistake in code changes for some bugfix or improvement. Because there was no test script for such case we didn't observe this regression then. As stated before, regressions happen when there's not enough test-case scripts.
I do not have any such test-case scripts, but just my real and daily Roundcube life. It's in fact the one and only MUA I'm privately using, and that's most likely the reason why I'm hitting many more brick walls than the developers do.
So a good idea would be: Do not only develop the stuff, but also USE it. ;) (But of course, please also keep developing it!)
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 05/05/2013 12:25 AM, Michael Heydekamp wrote:
May I ask: What was the cause? That there was a line longer than 76 chars without any whitespace, or that there was a DASHED line longer than 76 chars without any whitespace?
It was a line with no spaces, longer than a length limit. It doesn't matter what characters were in there, it could be not only dashes.
Am 05.05.2013 09:22, schrieb A.L.E.C:
On 05/05/2013 12:25 AM, Michael Heydekamp wrote:
May I ask: What was the cause? That there was a line longer than 76 chars without any whitespace, or that there was a DASHED line longer than 76 chars without any whitespace?
It was a line with no spaces, longer than a length limit. It doesn't matter what characters were in there, it could be not only dashes.
Thanks for this info, Alec.
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
-
A.L.E.C -
Michael Heydekamp