Bug 162673

Summary:	Content-Transfer-Encoding set to 7bit with utf-8 charset (and all chars except Latin are lost)
Product:	[Applications] kmail	Reporter:	Sergei Beilin <sbeilin>
Component:	general	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED FIXED
Severity:	grave
Priority:	HI
Version:	SVN trunk (KDE 4)
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed In:

Description Sergei Beilin 2008-05-26 21:39:49 UTC

Version:           svn r812925 (+/-) (using Devel)
Installed from:    Compiled sources
Compiler:          g++ (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7) 
OS:                Linux

Content-Transfer-Encoding is now always "7-bit". That's OK with English language and Latin chars, but all national (Russian for me) chars are lost, no matter utf-8 or koi8-r is used. This happens both to the sent message and it's copy in "Sent" folder.

For multy-part messages, the text/html part with utf8 charset is transferred as base64 (and no chars lost :), but the text/plain is partially (!) corrupted with some chars lost and wrong linebreak (it seems at 1/2 of the amount set, but that's another bug). These lost chars are at these linebreaks. It seems that it is first encoded and then linebreaked :)

Comment 1 Sergei Beilin 2008-05-28 08:19:50 UTC

Even if I hardcode base64 cte in kmmessage, russian letters are lost. Is it a bug in KRichTextEdit?

Comment 2 Sergei Beilin 2008-05-28 14:35:09 UTC

Well, mComposeWin->mEditor->textOrHtml() works fine!
At the same time, mComposeWin->mEditor->toWrappedPlainText() looses everything but latin chars.
Is it a bug in KMeditor::toWrappedPlainText()? Have to dig in QTextDocument, QTextBlock, QTextLayout and QTextLine for some toLatin1() conversion?

Comment 3 Thomas McGuire 2008-05-29 20:27:27 UTC

SVN commit 814242 by tmcguire:

Don't eat non-ascii characters when sending messages.
Time for me to buy a few brown paper bags...

BUG: 162673


 M  +6 -12     kmeditor.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=814242