WeBWorK Problems

Issue with rendering a MO String

Issue with rendering a MO String

by Alex Jordan -
Number of replies: 3
I just noticed that this problem in the OPL:

Library/PCC/BasicAlgebra/ComparisonsAndBasicInequalities/CompareFractionOperations10.pg

which was contributed by us (PCC) has Chinese characters showing up in the solution. There seems (to me) to be nothing wrong with the source. Strings are added to the context:

Context()->strings->add('<'=>{},'>'=>{},'='=>{});

And then these may end up as an $answer. Depending on the seed, maybe the answer is:

$answer=String('<');

But then this appears in the solution, in PGML:

Since [`[$neg_numer_left]`] [`[$answer]`] [`[$neg_numer_right]`],

and the $answer shows up as a Chinese character with \textbf{} around it. I can see that this line should really be:

Since [`[$neg_numer_left] [$answer] [$neg_numer_right]`],

but that still brings in the Chinese character.

  1. Is there a MathObject String bug here?
  2. Is there a PGML bug here?
  3. Is it really my fault for trying to use the less-than character in this unconventional way?




In reply to Alex Jordan

Re: Issue with rendering a MO String

by Davide Cervone -
Here's what's happening. The String object's TeX output is not intended to be part of a larger math expression, and it is set up to reproduce the string output verbatim. To that end, it uses the LaTeX \verb macro. This requires the use of a delimiter character to mark the beginning and end of the verbatim string, and that character can't be one of the ones used within the string. So the String object uses a non-ascii character as the delimiter so that it is less likely to appear in the text of the String object. I suspect that is what you are seeing, but you really shouldn't be seeing it, as both the MathJax and image output should properly handle that character as the delimiter. I think there was some work in 2.12 to handle unicode character better, so perhaps that is interfering with the use of the delimiter character used by the String object.

In any case, there are several possible solutions. First, you could force the String object to produce its string output rather than its TeX output, which will be the plain <, >, or =, which will format properly in TeX mode: 

Since [`[$neg_numer_left] [$answer->string] [$neg_numer_right]`]
Alternatively, you could use [$answer] outside of TeX mode, where PGML will handle the output properly (though the output will consist of two separate math expressions with a non-math character between them, which is less semantic for those using screen readers): 
Since [`[$neg_numer_left]`] [$answer] [`[$neg_numer_right]`]
Either should produce better results for you, but the former may be the better choice.

Davide

PS, are you sure you are getting \textbf{} around the less-than sign? I don't see where that could be coming from, though the \verb macro would typeset the result in the \tt font, which might look bold to you.

In reply to Davide Cervone

Re: Issue with rendering a MO String

by Alex Jordan -
Thanks Davide. I could certainly do something different with the code in these particular problems, but I wonder if the root issue (perhaps the unicode handling you mention) needs looking into. Maybe this is a rare corner case, but there could be other OPL problems adversely affected by the 2.12 changes. I would assume these problems were working in 2.11, since they are part of problem sets here that are regularly use. This one even has some global usage statistics.

The \bf looks to be built into the PG code for the problem, so never mind about that (sorry for the red herring). The Chinese character comes through like {\verbå¼…}" role="presentation">{\verbå¼…}.

Did you try loading the problem? I'm curious if it appears in other servers, 2.12 or otherwise. It's in the OPL:

Library/PCC/BasicAlgebra/ComparisonsAndBasicInequalities/CompareFractionOperations10.pg