Bug 219572 - composer hard wraps at window border
Summary: composer hard wraps at window border
Status: CONFIRMED
Alias: None
Product: kmail2
Classification: Applications
Component: composer (show other bugs)
Version: 5.3.1
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-21 17:39 UTC by Lars DIECKOW
Modified: 2021-11-01 02:53 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Pyramid shaped lines received when using wordwrap (107.14 KB, image/jpeg)
2010-07-23 21:34 UTC, Sabine Faure
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lars DIECKOW 2009-12-21 17:39:33 UTC
Version:           1.12.4 (using KDE 4.3.4)
OS:                Linux
Installed from:    openSUSE RPMs

To reproduce:
1. Enable option Word wrap at column 78. (This is set by default.)
2. Copy 5 long paragraphs of text, for example from <http://lipsum.com/feed/html>.
3. Paste the text into a new message window.
4. Resize the window, make it narrow so that about 30-40 characters fit in the composer window.
5. Save message as draft.
6. Go to drafts folder and visually inspect the message, perhaps also message sourcecode.

Expected behaviour:
Message text wraps at column 78.

Actual behaviour:
Message text wraps at whereever the window border was.

Rationale:
I was very emberassed when I found out that my mail program composed and sent out such an unsightly message. The window border should only ever wrap text for *reading*, never for *composing*.
Comment 1 Björn Ruberg 2010-03-10 23:25:04 UTC

*** This bug has been marked as a duplicate of bug 105485 ***
Comment 2 Thomas McGuire 2010-05-24 21:18:47 UTC
*** Bug 238629 has been marked as a duplicate of this bug. ***
Comment 3 Thomas McGuire 2010-05-24 21:20:05 UTC
Not a duplicate of the draft-related bug actually.
Comment 4 Leo Franchi 2010-07-19 22:26:24 UTC
SVN commit 1151892 by lfranchi:

Move flowText() from kdepim private to kdepimlibs/kpimtextedit/textutils.
Use flowText when wrapping plaintext in textedit, so that we don't h ave to rely on the wrapping of the QTextEdit, which might be incorrect if the widget width is smaller than the desired word wrap width.

BUG: 219572


 M  +4 -18     textedit.cpp  
 M  +44 -0     textutils.cpp  
 M  +13 -0     textutils.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1151892
Comment 5 Sabine Faure 2010-07-23 21:17:15 UTC
I retested this today and the wordwrap still does not seem to be set to 78 characters when the email is received.

Steps to reproduce:

- Launch Kontact and go to Kmail
- Click on 'New Message'
- Go to Option menu/Wordwrap and check box if not checked
- Enter a recipient(yourself)and a subject
- Type in a line of exactly 78 characters (ex: Testing wordwrap functionality using a line of exactly seventy eight caracters)
- Reduce the Composer window size so that two lines of text are displayed instead of one (ex: the first line should end after 'Using')
- Click on 'Send'
- Open the received message

The 78 characters are displayed on two different lines whereas it should not be the case.

Moreover, the same thing happens if the sender types a line of 75 characters instead of 78 (ex: Testing wordwrap functionality using a line of exactly seventy eight chars.)

Since this does not seem to be corrected so I am reopening this bug.

Trunk, Svn Rev 1153490
Comment 6 Sabine Faure 2010-07-23 21:28:50 UTC
If this helps here is another test I made:

- Copy the 78 characters line 5 times using a newline each time in the composer like so:
Testing wordwrap functionality using a line of exactly seventy eight caracters
Testing wordwrap functionality using a line of exactly seventy eight caracters
Testing wordwrap functionality using a line of exactly seventy eight caracters
Testing wordwrap functionality using a line of exactly seventy eight caracters
Testing wordwrap functionality using a line of exactly seventy eight caracters
- Reduce the size of the composer by half
- Send the email to yourself

When you open the received email the 5 lines have a sort of pyramid shape instead of being rectangular shaped (=5 time the exact same lenght of line).

Trunk, Svn Rev 1153490
Comment 7 Sabine Faure 2010-07-23 21:34:26 UTC
Created attachment 49443 [details]
Pyramid shaped lines received when using wordwrap
Comment 8 Marc Cousin 2010-07-26 22:00:48 UTC
I have exactly the same problem on 4.4.95, only a bit worse : I don't have to reduce the composer's windows to get the pyramid-shaped result from comment #7.

Word wrapping is unusable as it is.
Comment 9 Leo Franchi 2010-07-26 22:24:16 UTC
SVN commit 1155011 by lfranchi:

Use proper check for whether or not to linewrap. 

BUG: 219572
BUG: 238629


 M  +1 -1      textedit.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1155011
Comment 10 Leo Franchi 2010-07-27 22:00:30 UTC
Reopening this, as the fix was unsatisfactory. It really needs to be worked on in Qt, so we can use the QTextLayout to re-word-wrap the text if the window is too small.
Comment 11 Marc Cousin 2010-07-28 09:15:12 UTC
Yes, verified on my computer, this doesn't change the "Testing wordwrap functionality using a line of exactly seventy eight caracters" behavior.
Comment 12 Christine Bona 2010-07-29 10:51:56 UTC
Exactly the same bug affects word-wrapping in knode.
It is not useable at the moment.
Please consider this fact when you repair the functionality.

My KDE-version is: 4.4.95 (KDE 4.4.95 (KDE 4.5 >= 20100723)
Comment 13 Matt Whitlock 2011-06-11 14:39:48 UTC
I can deal with most of the bugs in KMail 2, but this one might single-handedly force me back to KMail 1.

If I have hard wrapping disabled (and I always do), then KMail should not be inserting hard line breaks anywhere in my message.  I'll press Enter if I want to insert a hard line break.

Soft line breaking at the composer window's width should be entirely handled by the view and should not affect the document model at all.  The text to be transmitted in the email comes from the document model, so why is the width of the view affecting it at all?
Comment 14 Denis Kurz 2016-09-24 17:52:49 UTC
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present?

If noone confirms this bug for a Framework-based version of kmail2 (version 5.0 or later, as part of KDE Applications 15.12 or later), it gets closed in about three months.
Comment 15 Tristan Miller 2016-09-25 16:20:15 UTC
I can confirm that the bug still exists in KMail 5.1.3 (KDE Applications 5.12.3).
Comment 16 Christophe Marin 2016-09-25 16:35:37 UTC
Thanks. This is also valid with git master