## WeBWorK Problems

### characters beyond the keyboard

by Alex Jordan -
Number of replies: 2
I'm working on a streamlined way to use GeoGebra in problems. One of the ways this new tool can be used involves GeoGebra sending WeBWorK a text string for a GeoGebra object. Sometimes, these strings use characters that go beyond keyboard ASCII. For example, GeoGebra might provide these strings:

x ≤ π

x⁶ + y⁶ = 1

In some cases, I may be able to get GeoGebra to behave differently. For example, I may be able to get GeoGebra to send out that last one as "x^6 + y^6 = 1". But in other cases, like with the degree symbol, GeoGebra will not be able to provide that in an alternative form.

I am aware that there is a lot of work underway so that WeBWorK will support using general utf-8 characters. Can someone explain what this might mean for my GeoGebra project? Here are some specific questions.
1. Will it be possible to add the character π to a MathObjects context as a constant equivalent to the constant "pi"?
2. Will it be possible to add the character ≤ to a MathObjects context as an operator like how some contexts understand "<="?
3. Will it be possible to add characters like ⁶ to a context as a unary operator with the appropriate associativity so that is equivalent to "^6"?
4. Will it be possible to add ° to a context in some way that makes sense?
5. Is any of this already possible in 2.14?
Obviously I am asking about adding these things to a context. As an alternative I could try to catalog all of these things in parserGeoGebra.pl and always translate them to more basic strings first. Would that be more wise?

### Re: characters beyond the keyboard

by Michael Gage -
The short answer is yes. You can use any unicode character in version 2.15 (currently in develop as a beta release for this spring). You can probably do most of what you are talking about in 2.14 already. We've been creeping toward utf8 compatibility for 4 or more years. There might still be some glitches in 2.15 but they would be bugs -- sections we just missed while making the code work with utf8. ( For example lexical ordering in utf8 characters and distinguishing between text and non-text files would seem to be good hunting grounds for bugs. )

To get full compatibility in either 2.14 or 2.15 you need to switch the tables for the course in the mysql database to use "utf8mb4" , the 4 byte representation of characters. I'd appreciate volunteers to help with preparing documentation detailing the best way to make the switchover from "latin-1" to "utf8mb4".

After the switchover to utf8 you can use your characters and even emoji. :-) Additional code will need to be added to MathObjects to define the behavior of the character.
In the meantime, a hack to get it to work might be to have the javascript code that transfers the GeoGebra data into the hidden input field perform some replace() calls that translate "π" to " pi " (with spaces so that it will not accidentally parse as part of some other word), and so on.
If there is no javascript that does that, then perhaps the submitAction() function could be used to handle the replacements. It could use document.querySelectorAll('input[type="text"]') to get all the input fields and loop through them to modify their values, replacing unicode characters by their equivalent ASCII representations. This would run when any submit button is pressed, before the form is sent to the server, so it should be possible to pre-process the unicode in this way.