Tickets :: [#2702] Preference for default encoding

6.0.0-beta1

9/5/25

Summary	Preference for default encoding
Queue	IMP
Queue Version	HEAD
Type	Enhancement
State	Resolved
Priority	2. Medium
Owners	slusarz (at) horde (dot) org
Requester	ditsa (at) ccf (dot) auth (dot) gr
Created	09/29/2005 (7281 days ago)
Due
Updated	03/31/2006 (7098 days ago)
Assigned	10/25/2005 (7255 days ago)
Resolved	03/31/2006 (7098 days ago)
Milestone
Patch	No

03/31/2006 10:58:01 PM	Michael Slusarz	Comment #10 State ⇒ Resolved	Reply to this comment
All coding should be completed. Tests have been working for me. Enhancement has been completed so closing ticket - bug reports should go into new tickets.

03/24/2006 03:58:43 PM	Jan Schneider	Comment #9	Reply to this comment
Makes sense. Changed in CVS.

03/24/2006 03:53:36 PM	Michael Slusarz	Comment #8	Reply to this comment
But they will do anyway if you use that feature, right? I can't really test it unfortunately, because Cyrus doesn't allow unencoded 8bit characters in headers anyway. The way you changed the preference, then yes. That's why I originally had the preference set to '' (for Default RFC Encoding) by default. If we would have a blank option, and ship with blank (i.e. us-ascii) as the default, then the 'default_charset' globals don't get set and none of the convertCharset() calls are triggered. I guess what I am trying to say is I believe we should ship with the default as 'US-ASCII' (i.e. replace the 'ISO-8859-1' entry with US-ASCII) since this is the "proper" RFC-compliant charset to use by default.

03/24/2006 09:34:45 AM	Jan Schneider	Comment #7	Reply to this comment
[Show Quoted Text - 11 lines][Hide Quoted Text] You also need to use the default charset for the email headers. So we have to run every header line through String::convertCharset()? In that case, we really need to change the preference defaults back to 'US-ASCII' rather than this code: 'value' => isset($GLOBALS['nls']['emails'][$GLOBALS['language']]) ? $GLOBALS['nls']['emails'][$GLOBALS['language']] : (isset($GLOBALS['nls']['charsets'][$GLOBALS['language']]) ? $GLOBALS['nls']['charsets'][$GLOBALS['language']] : 'ISO-8859-1'), Because those convertCharset calls are going to add up in a hurry. But they will do anyway if you use that feature, right? I can't really test it unfortunately, because Cyrus doesn't allow unencoded 8bit characters in headers anyway.

03/24/2006 05:46:18 AM	Michael Slusarz	Comment #6	Reply to this comment
First attempt at converting headers has been completed.

03/24/2006 04:49:53 AM	Michael Slusarz	Comment #5	Reply to this comment
You also need to use the default charset for the email headers. So we have to run every header line through String::convertCharset()? In that case, we really need to change the preference defaults back to 'US-ASCII' rather than this code: 'value' => isset($GLOBALS['nls']['emails'][$GLOBALS['language']]) ? $GLOBALS['nls']['emails'][$GLOBALS['language']] : (isset($GLOBALS['nls']['charsets'][$GLOBALS['language']]) ? $GLOBALS['nls']['charsets'][$GLOBALS['language']] : 'ISO-8859-1'), Because those convertCharset calls are going to add up in a hurry.

03/23/2006 05:22:01 PM	Jan Schneider	Comment #4 Assigned to Michael Slusarz Taken from Jan Schneider	Reply to this comment
You also need to use the default charset for the email headers.

03/21/2006 08:00:53 AM	Michael Slusarz	Comment #3 State ⇒ Feedback	Reply to this comment
First crack at this is now in HEAD and 4.1.1. It requires at least Horde 3.1.1.

10/25/2005 12:35:48 PM	Jan Schneider	Version ⇒ HEAD

10/25/2005 08:54:44 AM	Jan Schneider	Assigned to Jan Schneider State ⇒ Assigned

09/29/2005 08:41:54 AM	Jan Schneider	Comment #2 Summary ⇒ Preference for default encoding State ⇒ Accepted	Reply to this comment
I probably don't have to tell you that hotmail is sending completely broken messages. But this happens with so many mailers that it makes sense to define a default encoding for messages that don't define a proper charset. This has been requested several times, as such a feature exists in other mail clients too. I plan to implement this for a while already, but didn't get to it yet. A patch would be great. But this shouldn't be a selection in the message view, but a preference for all messages.

09/29/2005 08:30:24 AM	ditsa (at) ccf (dot) auth (dot) gr	Comment #1 Priority ⇒ 2. Medium Type ⇒ Enhancement Summary ⇒ IMP encoding problem Queue ⇒ IMP State ⇒ New	Reply to this comment
I have a problem with the encoding in IMP when I? m reading Greek in a message from hotmail or Outlook. Both don?t include encoding information in the subject, while hotmail doesn?t as well include encoding headers information, which is responsible for the body of the message. Is there a way to include a drop-down menu in the message window with encoding options or the encoding in the above-mentioned cases to be selected automatically according to the chosen by the user language (e.g. ISO-8859-7 for Greek)? We are willing to contribute with code if necessary in order to provide this feature.