I played some more with this...
Using PG carefully initdb'ed and run with LANG=C, and with AOLserver 3.2+ad12 or 3.3+ad13 I can *still* get incorrect display of ISO 8859-1 (Latin 1) characters from OpenACS.
However, when I get rid of OpenACS and just run the exact same copy of AOLserver... the problem disappears!
Here is what I did:
#!/bin/bash
#
# iso8859test - sets up ISO 8859-1 test pages for AOLserver and OpenACS
#
# Generate ISO 8859-1 charset table from man page
man iso_8859_1 |col -b |egrep "^ *[0-9]" >iso_8859_1.txt
# Generate head and tail for HTML test pages
cat >iso_8859_1.html.head <<EOF
<HTML>
<HEAD>
<TITLE>ISO 8859-1 Test Page</TITLE>
</HEAD>
<BODY>
<PRE>
EOF
cat >iso_8859_1.html.tail <<EOF
</PRE>
</BODY>
</HTML>
EOF
# Create ISO 8859-1 test page
cat iso_8859_1.html.head iso_8859_1.txt iso_8859_1.html.tail >iso_8859_1.html
This generates a nice HTML page containing all the non-USASCII printable characters in ISO 8859-1. Then I checked I could view this file OK in my browsers. Next I copied it to /var/www/html/ (where Apache can serve it) and to /var/lib/aolserver/servers/default/pages/ (where AOLserver can serve it) and to /var/lib/aolserver/servers/defaultacs/www/ (where OpenACS can serve it).
Apache serves it fine. OpenACS serves it with extra "A-with-circumflex" characters. But, if I do
cd /var/lib/aolserver/servers
mv defaultacs defaultacs.old
And then do /sbin/service aolserver restart, AOLserver can
then serve it just fine.
I repeated the test using AOLserver 3.2+ad12 and 3.3+ad13, no difference was noticed.
Conclusion: Something about the way OpenACS serves plain .html files breaks ISO-8859-1 output under OpenACS 3.2.5. It looks to me as though the primary bug here is in OpenACS 3.2.5 itself, not in PG or AOLserver.
