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.
pgpMFNCES5SZH.pgp
Description: PGP signature
------------------------------------------------------------------------- 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
