Hello, just my 2 cents.
Ichikawas suggestion makes a lot of sense. Traditionally all mail agents in Japan were using iso-2022-jp (Shin-JIS) but nowadays more and more programs are understanding other charsets including UTF8. So it does make sense to separate the browser charset from the charset used for mail and I hope that we will see this change in the near future. If possible at all I'd like to see a) a configuration setting (as suggested by Ichikawa) b) the possibility to override the charset for single mails (b) is useful for people like me who frequently need to write and read mails in different languages. Actually, the mail agent (Sylpheed) I'm using allows me to change the charset but unfortunateley it is a general setting affecting all mail. I could have changed it for this mail but then I might forget to change it back afterwards with the results that all the Japanese complain because they can't read my mails anymore... For such reason it would be handy to have an option to change it by mail or by session. Also the charset in use should be clearly displayed as a reminder. Best regards and thanks for a ever improving program! Bernd On Mon, 09 Feb 2004 18:55:34 -0500 Sam Varshavchik <[EMAIL PROTECTED]> wrote: > Toshikazu Ichikawa writes: > > > > >> There are several problems in your implementation. Specifically, you cannot > >> make any references in rfc822 to symbols defined in the sqwebmail directory. > >> This is because rfc822 is a generic library that's also shared by other > >> applications. > > > > Yes, You are right. I have to fix it. > > > >> You'll have to do better than this. You are making drastic changes to the > >> rfc2047 functions, and you need to provide a better explanation. > > > > Drastic changes are due to OUTGOING_CHARSET work. > > I don't see anything in 2047 that could possibly relate to OUTGOING_CHARSET. > > > RFC2047 MIME-encoding header should be less than 76 character length, > > and furthermore the length of header string is unpredictable, > > which is converted into outgoing charset coding. > > So I modified rfc2047 encoding function. > > > > The rfc2047 compliance bug I want to designate and I fixed, > > An 'encoded-word' MUST NOT appear within a 'quoted-string'. > > > > Anyway, many apologies to my less words. > > I think that rfc2047_encode functions should be rewritten, possibly with a > different API (and changing everything that calls them accordingly). > > I would like to see a completely separate patch for OUTGOING_CHARSET first. > Then, if you can come up with a simple, separate patch to fix > rfc2047_encode, then that might work. But if it really is drastic surgery, > then save your time. I'll probably end up looking at and rewriting these > functions anyway. This might be one of the cases where it's just better to > have a clean start. It's not a lot code, so it shouldn't be too bad. > >
