Yes, I just reinstalled a prior rpm without the reversion to cgi/cgi.c but
with the  --enable-unicode and  --enable-unicode=utf-8,iso-2022-jp,iso-8859-1
flags and it was working fine. I'm not sure why I didn't see this working
before, I'm sure I restarted courier after installing this version of the
rpm. Anyway, disregard the previous claims of problems with that patch, the
correct way to resolve the display issue is to add the appropriate
--enable-unicode flags and be more clueful about restarting the services.

Thanks Mr. Sam

-----Original Message-----
From: [EMAIL PROTECTED] on behalf of Sam
Varshavchik
Sent: Sat 1/27/2007 5:20 PM
To: [email protected]
Subject: Re: [courier-users] Issue with webmail utf-8/iso-2202-jp display
 
Jason Benguerel writes:

> 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.

The code in cgi.c has nothing to do with text output, but with parsing input 
to the cgi.  So, I'm afraid that you have some more digging left to do, on 
your part, to understand what the real problem is.

The original problem was that in utf-8, 0xA0 may be a part of a multibyte 
sequence, and not a non-breaking space.  So, mangling 0xA0 back to 0x20 
actually broke valid UTF-8 input.

Now, the pre-1.33 code was the one that was actually mangling the input to 
the cgi, and the mangling was removed in 1.33.  If anything, it should be 
the other way around, since now sqwebmail will not mangle the input it 
receives from the browser.  Originally, non-breaking spaces in the input 
were mangled back to an ordinary space, due to some issues with early 
pre-utf8 browsers.  This was the only change in 1.33.





-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Reply via email to