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.
6 messages in net.sourceforge.lists.courier-usersRe: [courier-users] Issue with webmai...
