Mr. Sam and all,
I backed out the recent patch to cgi/cgi.c (reverted to 1.32) and this
resolved the display issue.
I had prior to this reversion inserted some test utf-8 encoded text into
several sqwebmail templates to insure that it wasn't an issue with the
webserver configuration, and concluded that the text wasn't getting mangled
by the server or the cgi processing code. This led me to back out the most
likely suspect. If you can explain how this substitution of the unicode
non-breaking space was breaking the calendaring application I can attempt to
offer a better way to resolve the issue.
I'm not sure why the Japanese language maintainer didn't notice this
breakage, I'm guessing that this happens using utf-8 rather than pure
iso-2022-jp encoding.
Jason
-----Original Message-----
From: cour...@lists.sourceforge.net on behalf of Sam
Varshavchik
Sent: Fri 1/26/2007 3:55 PM
To: cour...@lists.sourceforge.net
Subject: Re: [courier-users] Issue with webmail utf-8/iso-2202-jp display
Jason Benguerel writes:
I just did a major server upgrade and moved my mail services to a new
machine. I'm using courier-0.54.2 built via the rpmbuild mechanism with
--disable-autorenamesent and with_fax 0 as the only modifications to the
spec file. The issue is that webmail doesn't seem to want to correctly
display my ISO-2022-JP mail anymore. It is serving it with the
Content-Type:
If that's the only non-default option you used, then sqwebmail simply does
not know anything about iso-2022-jp. By default, only utf-8 and iso-8859-1
character maps get compiled in.
Recompile with the --enable-unicode option.
6 messages in net.sourceforge.lists.courier-usersRe: [courier-users] Issue with webmai...
