Version: 1.5.1 (using KDE 3.1.2) Installed from: SuSE Compiler: gcc version 3.3 20030226 (prerelease) (SuSE Linux) OS: Linux (i686) release 2.4.21 While composing, Kmail misdisplays Euro Signs as "crossed circle", even after selecting iso-8859-15 as the encoding. When attempting to send the mail, it pops up a cryptic error message ("Not all characters fit into the chosen encoding. Send the message anyway?"), and upon clicking yes, the euro-signs are replaced with question marks (ascii 63). Please fix this. N.B. This is not the only character set issue in KDE 3.1.2 . In many other apps, setting up default character encodings has become increasingly difficult, or sometimes buggy. I remember that in previous versions this has been a lot easyer. N.B. The problem has been observed when using emacs (or rather: gnuclient) as an external editor. Emacs shows the euro sign correctly. Only after Ctrl-X # is it shown as the infamous iso-8850-1 crossed circle in kmail. When switching off external editor, kmail shows a blank square instead of Euro. From what I've heard, KDE is trying to use some kind of "smart" autodetection to guess what the user wants, but it seems in many situations this does not work out. Please provide a (working) option to allow the user to say explicitly what he wants.
Subject: Re: New: kmail composer with external editor botches character set encoding KMail interprets the text it receives from the external editor as encoded according to the local encoding. Do you really want to be asked which encoding the external editor used to save the message each time you close the external editor? Simply set your local encoding (e. g. LC_ALL) to the correct encoding which is de_DE@euro IIRC. > When switching off external editor, kmail shows a blank square > instead of Euro. Did you enter the Euro symbol in KMail's composer? > From what I've heard, KDE is trying to use some kind of "smart" > autodetection to guess what the user wants, but it seems in many > situations this does not work out. Actually all Unix programs out there use the local encoding by default. So KDE programs are not trying to be smarter than any other Unix application (maybe apart from some applications which are hardcoded to use latin1).
It works. Sorry for the harsh tone of my mail, I was trying to prevent a reply similar to those about a similar problem with konsole (http://bugs.kde.org/show_bug.cgi?id=46268). Btw, your suggested environment variable setting also fixes the problem in konsole. Thanks very much! Part of the confusion came from old howto's, which suggested to set LC_ALL to de_DE.iso8859-15 instead, which worked in older versions of KDE, but no longer now. However, I'm still puzzled as to the purpose of the "Options->SetEncoding" menu option, if the real way to do it is set an environment variable. Wouldn't it also be appropriate to add a sentence to the "Not all characters fit into the chosen encoding..." dialog box saying "If you wish to send an e-mail containing a Euro sign, set LC_ALL to de_DE@euro" or sth similar?
That option is, I believe, for KMail's own composer. When it composes the message, it will try to use the first encoding that works to encode the whole text. If you have utf-8 in your list, the encoding will always succeed. The problem is only with external editors. There's no other communication mechanism for the external editor to tell KMail what the encoding is -- unless it wrote a MIME header.
> That option is, I believe, for KMail's own composer. I see. > When it composes the > message, it will try to use the first encoding that works to encode the whole text. If > you have utf-8 in your list, the encoding will always succeed. But, in that case, the person receiving the mail may not succeed in decoding it, depending on what mail program he uses (pine?, elm?). Using utf-8 is somewhat premature, IMHO, given that many apps may not yet be able to correctly deal with it... >The problem is only with external editors. There's no other communication > mechanism for the external editor to tell KMail what the encoding is -- unless it > wrote a MIME header. And naively, I thought that this menu option was that communication mechanism...
Subject: Re: kmail composer with external editor botches character set encoding On Wednesday 02 July 2003 14:31, Alain Knaff wrote: > > When it composes the > > message, it will try to use the first encoding that works to encode > > the whole text. If you have utf-8 in your list, the encoding will > > always succeed. > > But, in that case, the person receiving the mail may not succeed in > decoding it, depending on what mail program he uses (pine?, elm?). > Using utf-8 is somewhat premature, IMHO, given that many apps may not > yet be able to correctly deal with it... Then simply add some encodings which should be tried before utf-8 to the list of Charsets in the Composer section of the settings dialog. But if none of those charsets works then utf-8 has to be used. If you want to be 8-bit clean then simply don't use the Euro symbol but use EUR instead. I close this bug report because the problem was apparently resolved. I close it as invalid because it was no KMail problem.