WeBWorK Problems

characters beyond the keyboard

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:

5°

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?


In reply to Alex Jordan

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 reply to Alex Jordan

Re: characters beyond the keyboard

by Davide Cervone -
Once non-ASCII unicode character are allowed in input fields, you should be able to process them via MathObjects by defining the proper values in the context (as Mike suggests). Moist of the name patterns would need to be changed, however, as they currently only allow ASCII characters, but that can certainly be done. Something like π to be equivalent to "pi" is easy. Same for ≤. You would need to be sure to include TeX commands for their output, as I don't think latex will handle the unicode characters (there may be a package that allows for that). These could be done with just configuration of the context.

Using ⁶ for "^6" would be possible, but would take making a new class to process the operator, but that can be done.

For ° you could create an operator (right-associative) that multiplies its argument by pi/180, I suppose. If you want to make it work with NumberWithUnits, you would have to define a new unit ° that is equivalent to "degrees", but that could be done.

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.