** Using WeBWorK **

Several web pages doesn't display correctly when the character encoding in the web browser is set to Western (ISO-8859-1), which I believe is the default browser setting for character encoding. If I use Unicode (UTF-8) encoding, the page displays fine. One example where things look wrong is on a course-login page, where the blue bar on top should contain something like this:

WeBWorK -> coursename

When viewed in ISO-8859-1 encoding I see some "funny" characters instead of the "->"

Can anything be done about this?

Lars.

<| Post or View Comments |>

We've designed WeBWorK to use UTF-8 encoding in its output. Every WeBWorK page includes an HTML tag that directs your browser to use the UTF-8 character set when displaying the page:

<meta http-equiv="content-type" content="text/html; charset=utf-8" />

Your browser "should" automatically switch to UTF-8 mode when it encounters this tag. What browser are you using?

As far as I know, the only non-ASCII character currently in WeBWorK is the arrow you describe. You can change that arrow to another character by editing conf/templates/math/system.template and conf/templates/math/gateway.template.

Hope this helps.
-sam

<| Post or View Comments |>

It looks like WeBWorK may not be doing all it can to specify character encoding. According to the Character encodings section of the XHTML spec, the best approach is to send the character encoding as part of the Content-Type HTTP header. We don't do that.

It goes on to say that if the encoding isn't specified in the Content-Type header, it should be specified both in a meta tag and in the XML declaration. We don't use an XML declaration. (I think there's a good reason why we don't but I don't recall what it is at the moment.)

I'll look into adding the encoding to the Content-Type HTTP header, since that's the recommended method.

See Bug #1030.

Thanks.
-sam

<| Post or View Comments |>

We tried with bot Firefox (on windows and linux), and (IE on windows). In both cases we saw the arrow replaced by "funny" characters. The browser did not automatically switch to UTF-8 encoding - we had to do that manually. -And each time I went on to another page, the browser encoding would go back to the default mode (ISO-8859-1), and had to be switched to UTF-8 manually again.

Lars.

<| Post or View Comments |>

I can't reproduce this on Firefox 1.5.0.3 for Mac. The default encoding is iso-8859-1, but when a WeBWorK page loads, it correctly switches to utf-8. It works whether or not "Auto Detect" is on. I also tested on WinIE 6.0.2900.2180.xpsp.050928-23367. Worked fine there too.

You can try replacing the following in the subroutine header in lib/WeBWorK/ContentGenerator.pm:

Existing line:

$r->content_type("text/html");

Replace with:

$r->content_type("text/html; charset=utf-8");

Let me know if that helps.
-sam

<| Post or View Comments |>

That did he trick.

Thanks! Lars.

<| Post or View Comments |>

After a recent OS upgrade, we were getting exactly this problem on Firefox 1.5.0.3 for Mac, even though Safari was displaying correctly. The easiest fix was to change the AddDefaultCharSet directive in httpd.conf to:

AddDefaultCharset UTF-8

Using AddDefaultCharset off also worked, but I gather there are security issues with this (http://www.apache.org/info/css-security/). This seems to be a complicated subject; I hope our fix is safe.

Bob

<| Post or View Comments |>

It appears that setting AddDefaultCharset to utf-8 has the same effect as the $r->content_type fix I offered above.

The $r->content_type fix will be included in release 2.2.1 of WeBWorK. Until then, it is reasonable to use AddDefaultCharset instead, to avoid modifying the source.
-sam

<| Post or View Comments |>