Bug 103800 - Font encoding is ignored when opening message in new window
Summary: Font encoding is ignored when opening message in new window
Status: RESOLVED WORKSFORME
Alias: None
Product: kmail
Classification: Applications
Component: messageviewer (show other bugs)
Version: 1.8
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
: 107092 109490 109569 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-04-13 16:40 UTC by Zbigniew Luszpinski
Modified: 2007-09-18 19:31 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zbigniew Luszpinski 2005-04-13 16:40:22 UTC
Version:           1.8 (using KDE 3.4.0, compiled sources)
Compiler:          gcc version 3.3.3
OS:                Linux (i686) release 2.6.11.6

Most e-mails I get (or send) is encoded in ISO-8859-2. All of them display correctly in message preview if I single click on message's subject in messages list. If I choose from menu: "View->Show source V" the message source is also displayed correctly.

The problem

is when I _double click_ on message's subject in message list. The message is opened in new window but encoding _is lost_.
Comment 1 lpetersen 2005-04-25 15:00:34 UTC
I can confirm this problem, which also applies to printing messages from KMail. UTF-8 encoded messages are printed as though they were encoded in ISO-8859-1 (it seems), although I have set UTF-8 as standard encoding in KMail's Settings (Appearance -> Message Window -> Standard Coding or sth like that).
Comment 2 Zbigniew Luszpinski 2005-05-05 18:17:59 UTC
Hi lpetersen@gmx.net

I also tried your tip (KMail's Settings: Appearance -> Message Window) by setting everywhere ISO-8859-2. It did not help me also. You have right, I also think this is ISO-8859-1 codepage hardcoded into KMail. I have no idea why someone have done such strange thing.
Comment 3 Hauke Laging 2005-07-21 09:22:48 UTC
*** This bug has been confirmed by popular vote. ***
Comment 4 Thiago Macieira 2005-07-29 05:55:27 UTC
*** Bug 107092 has been marked as a duplicate of this bug. ***
Comment 5 Thiago Macieira 2005-07-29 05:55:54 UTC
*** Bug 109569 has been marked as a duplicate of this bug. ***
Comment 6 Jaroslaw Jan Pyszny 2005-08-03 02:08:36 UTC
I testing Peter solution (Bug 107092) and I think this is problem with 'encoding=' in '[Reader]' section.
I had before making the test ('[Reader]'):
....
encoding=Automatycznie
...
after:
...
encoding=
...

PS.
In log file I had:
ASSERT: "0" in kmreaderwin.cpp (1098)
Comment 7 Wilbert Berendsen 2005-10-03 14:18:09 UTC
In KDE 3.5 Beta 1 the same problem now also occurs in the regular, embedded messageview of Kontact:

When the message headers contain:
X-Mailer: Microsoft Outlook Express 6.00.2900.2527
Content-type: text/plain;
  format=flowed;
  charset=utf-8;
  reply-type=original
Content-transfer-encoding: 8BIT

the message is displayed in iso-8859-1, which causes the utf-8 characters to be displayed wrongly.


Comment 8 Wilbert Berendsen 2005-10-24 14:33:51 UTC
This bug is still in KDE 3.5 beta 2.

Not only the separate message viewer window does not display utf-8 encoded messages properly, but also the embedded message preview window.

And also when printing the encoding is wrong.
Comment 9 Wilbert Berendsen 2005-10-24 21:56:41 UTC
Hm, I have to rectify: It seems the bug went away after opening the KMail settings and re-selecting the Secundary and Primary text encoding. I just reselected them, no changing.

But now the message viewer and the preview display the message in the correct encoding.

Even the raw message view has the correct encoding, if specified in the main headers (not if specified in a body mime part).
Comment 10 Thiago Macieira 2005-10-25 03:11:55 UTC
This bug is not marked as fixed.
Comment 11 Zbigniew Luszpinski 2006-06-15 23:17:14 UTC
Opening iso-8859-2 message in new window shows correct output. Thanks for fixing. KMail 1.9.3, KDE 3.5.3.
Comment 12 Rolf Eike Beer 2007-09-18 19:31:04 UTC
*** Bug 109490 has been marked as a duplicate of this bug. ***