Version: 1.6.2 (using KDE KDE 3.2.1) Installed from: SuSE RPMs I have an email with a body part that clearly states "Content-Type: text/plain; charset=ISO-8859-1; format=flowed" in the original source. When I single click the email the preview pane shows me boxes instead of accented French characters. When I double click, the newly opened preview window does show the email correctly. I can easily reproduce mails that will give the above behavior: send an email with an attachment and some accented characters in the body. If you remove the attachment by editing the source, the email is rendered correctly. So I assume it has something to do with attachments. I will attach the email source as on disk, two screenshots: one for the first preview and one for the second preview.
Created attachment 6542 [details] This is a screenshot of how the email is shown inline.
Created attachment 6543 [details] This is a screenshot of how the email is shown in a new window
Created attachment 6544 [details] This is the original source of the email.
This happens also for German Umlauts. The Umlauts appear as two small boxes in the preview as well as in the Message display window. iso-8859-1, iso-8859-2, iso-8859-15, us-ascii, utf-8, and utf-8(local) is specified. Especially I have recognized this with messages marked as HTML Message.
I can confirm what Wolfgang Kurz said for SuSE 9.1 RPMs and KDE 3.3.0 too. The previewpane and the viewpane display umlauts wrong. Editing (f.e. forward/reply) or "Show message code" works! Changing the font for the message (pre)view doesn't help. Also printing is wrong. As SuSE 9.1 introduced the UTF-8 local as standard, is switched back to de_DE@euro (which seem to set charcode to ISO8859-15). This makes the display of messages work correctly again. So it seems that in the (pre)view the locale "UTF-8" doesn't work.
Bravo, the mail you attached is properly displayed when I set the decoding policy to Auto, which is the default, I believe. (View -> Set Encoding -> Auto). The Content-Type: text/plain; charset="iso-8859-1" is correctly parsed and applied. If I set select iso-8859-1 explicitely, all is fine as well, if I select utf8, I get the boxes you describe. So far this seems all perfectly allright to me. Wolfgang, Rudolf, any example mails that trigger this for you? What is your decoding policy set to? Auto, I presume?
Created attachment 7576 [details] This is a email with wrong displayed umlauts when local is set to "...UTF-8" and "View-Enconding" is on "auto". The mail is fetched directly from the imap store. Tim, this was a excellent hint to change the view coding. But - for me it _was_ set to "auto" and the text display is garbled. Setting the "View->Set Enconding" manually to "8859-15" the text is displayed correctly. FYI: for this, is switched my LANG from "de_DE@euro" back to "de_DE.UTF-8". I attach a mail which umlauts are displayed wrong for "de_DE.UTF-8" and "View -> Set enconding" is on "auto". It seems the wrong charcode selection of "auto" comes from a missing "charset=..." entry in the mail. Could a "Use encoding XXXXX if no charcode found in email"-switch as a fallback solve the problem?
That's exactly what we do. We fall back to the system encoding, which in the case of de_DE.UTF-8 is utf8. If you set your system to use de_DE@euro, it will use iso-8859-1, or 15, so things will look allright. I don't see where KMail is doing something wrong here. The mail you attached doesn't specify an encoding. KMail uses your system encoding, which is utf8. The mail is therefor misrendered, unless you manually addjust the encoding via View -> Set Encoding. If you set your system encoding to be something else, it will fall back to that, which can be wrong just as easily, if you get an email that is encoded in utf8 and doesn't say so via the encoding header.
Yes, i understand. Setting the "View-..Encoding" to the correct value für the mail displays the char's right. But - unfortunately printing the mail is not affected bye "View...". The printout is garbled and unreadable. I agree that a good mua should set the enconding. It seems to my that many webmailer doesn't. Could the actual "View-...Encoding"-setting applied to the printout? BTW: For me, kmail is the best MUA you can find.
CVS commit by tilladam: Use the override codec for printing from the main readerwindow and from a standalone readerwindow if one is set. Ingo, backport? CCMAIL: 84425@bugs.kde.org M +3 -2 kmcommands.cpp 1.171 M +3 -1 kmcommands.h 1.49 M +3 -2 kmmainwidget.cpp 1.264 M +1 -1 kmreadermainwin.cpp 1.32 --- kdepim/kmail/kmcommands.cpp #1.170:1.171 @@ -1286,6 +1286,6 @@ KMCommand::Result KMBounceCommand::execu KMPrintCommand::KMPrintCommand( QWidget *parent, - KMMessage *msg, bool htmlOverride ) - : KMCommand( parent, msg ), mHtmlOverride( htmlOverride ) + KMMessage *msg, bool htmlOverride, const QTextCodec* codec ) + : KMCommand( parent, msg ), mHtmlOverride( htmlOverride ), mCodec( codec ) { } @@ -1297,4 +1297,5 @@ KMCommand::Result KMPrintCommand::execut printWin.readConfig(); printWin.setHtmlOverride( mHtmlOverride ); + printWin.setOverrideCodec( mCodec ); printWin.setMsg(retrievedMessage(), TRUE); printWin.printMsg(); --- kdepim/kmail/kmcommands.h #1.48:1.49 @@ -512,5 +512,6 @@ class KMPrintCommand : public KMCommand public: - KMPrintCommand( QWidget *parent, KMMessage *msg, bool htmlOverride=false ); + KMPrintCommand( QWidget *parent, KMMessage *msg, + bool htmlOverride=false, const QTextCodec *codec = 0 ); private: @@ -518,4 +519,5 @@ private: bool mHtmlOverride; + const QTextCodec *mCodec; }; --- kdepim/kmail/kmmainwidget.cpp #1.263:1.264 @@ -1479,6 +1479,7 @@ void KMMainWidget::slotPrintMsg() { bool htmlOverride = mMsgView ? mMsgView->htmlOverride() : false; - KMCommand *command = new KMPrintCommand( this, mHeaders->currentMsg(), - htmlOverride ); + KMCommand *command = + new KMPrintCommand( this, mHeaders->currentMsg(), + htmlOverride, mCodec ); command->start(); } --- kdepim/kmail/kmreadermainwin.cpp #1.31:1.32 @@ -95,5 +95,5 @@ void KMReaderMainWin::slotPrintMsg() { KMCommand *command = new KMPrintCommand( this, mReaderWin->message(), - mReaderWin->htmlOverride() ); + mReaderWin->htmlOverride(), mReaderWin->overrideCodec() ); command->start(); }
This bug is still present in HEAD at the time of writing this. The bug is triggered by the "load on demand" setting. If you disable this, kmail gets the encoding right for the preview window and also displays the relevant content-type lines for each part in the "view source" window.
[00:30] <[ade_]> till closed it, he's gone to bed though [00:31] <xt> [ade_]: he asked me to reopen if it still was present in HEAD ..
Add load on demand info to summary, move to imap component, assign to Carsten.
*** Bug 89834 has been marked as a duplicate of this bug. ***
CVS commit by burghard: Load also the mimeheader for other parts to get the encoding correctly. BUG: 84425 M +1 -2 bodyvisitor.cpp 1.12 --- kdepim/kmail/bodyvisitor.cpp #1.11:1.12 @@ -126,6 +126,5 @@ namespace KMail { } if ( !part->partSpecifier().endsWith(".HEADER") && - part->typeStr() != "MULTIPART" && - !part->loadPart() ) + part->typeStr() != "MULTIPART" ) part->setLoadHeaders( true ); // load MIME header