Radio buttons

[dpvc]

This pull request enhances the MathObject RadioButtons() macro in several ways.

• Button text can now contain arbitrary text, including mathematics. HTML and TeX special characters are handled properly. HTML and TeX special characters must be properly escaped by the problem author.
• Choices can be randomized automatically.
• Labels (e.g., A,B,C... or 1,2,3...) are now added based on the final ordering, not the initial ordering, and can be displayed as part of the button text automatically.

The ability to handle any text is implemented by updating the underlying bring MathObject class to handle arbitrary text properly (it was originally designed only to handle a single word, so didn't handle spaces or special characters properly).

See the updated documentation at the top of the file for how to handle randomization and labels. The changes should be backward compatible (all the original options are still processed, though some are no longer needed in light of the new randomization options).

Some PG code that can be used to test some of the new features include:

Context()->strings->add('">$%{}_^~<'=>{});
$s = String('">$%{}_^~<');

TEXT($s->ans_rule);
ANS($s->cmp);

for testing that the String object can handle the HTML and TeX special characters, in both screen and hardcopy.

loadMacros("parserRadioButtons.pl");

$radio = RadioButtons(['Item 1','math: \(x+1\)','Button3'],1);

BEGIN_TEXT
\{$radio->buttons\}
END_TEXT
ANS($radio->cmp);

to test mathematics in button text (in both screen and hardcopy),

loadMacros("parserRadioButtons.pl");

$radio = RadioButtons([["Button1","Button2","Button3"]],0);

BEGIN_TEXT
\{$radio->buttons\}
END_TEXT
ANS($radio->cmp);

and

loadMacros("parserRadioButtons.pl");

$radio = RadioButtons([
  "Button0",
  ["Button1","Button2","Button3"],
  "Button4",
  ["Button5","Button6","Button7"]
],0);

BEGIN_TEXT
\{$radio->buttons\}
END_TEXT
ANS($radio->cmp);

to test randomization,

loadMacros("parserRadioButtons.pl");

$radio = RadioButtons([["Button1","Button2","Button3"]],0,labels=>"ABC");

BEGIN_TEXT
\{$radio->buttons\}
END_TEXT
ANS($radio->cmp);

to test automatic labels, and

loadMacros("parserRadioButtons.pl");

$radio = RadioButtons([[
    "Button1",
    {"Math: (x+1)/(x-1)" => "Math: \(x+1\over x-1\)"},
    "Button3"
]],1,displayLabels=>0);

BEGIN_TEXT
\{$radio->buttons\}
END_TEXT
ANS($radio->cmp);

to test explicit labels (in this case, to make math format more reasonably in the results table).

[goehle]

Does it matter that this splits off of a branch called popup-menus. Are there upgrades to popup/dropdowns that I should look out for?

[dpvc]

It actually is the other way, popup-menus was branched from this (but the network diagram may not make that clear). I will make a pull request for popup-menus after this one is merged. Both branches needed the changes to the String object.

[goehle]

I've been testing this out and have run across some problems. The minor ones are:

• I can't get the checked or forceLabel options to do anything. In particular if checked is set, the radio button doesn't start checked, and forceLabel doesn't cause empty labels to appear if no labels are set.
• The maxLabelSize option doesn't work properly. If I set longish labels and set maxLabelSize to 3, I get string concatination warnings and the student answers are the full long label with some extra ...'s.

The big issue is that something is broken with string that is breaking some normal functionality. If I try to generate a graph, or a number of other things I end up with errors that look like.

 Your answer should be one of  or  at line 65 of [PG]/macros/contextString.pl

Some code that fails is

DOCUMENT();      
loadMacros(
   "PGstandard.pl",
   "MathObjects.pl",
);
loadMacros(
"parserRadioButtons.pl",
"PGgraphmacros.pl",
"unionTables.pl",
);

TEXT(beginproblem());
foreach my $j (0..6) {

 $graph[$j] = init_graph(-5,-5,5,5,'axes'=>[0,0],
              'ticks'=>[10,10],'size'=>[300,300]);
 $graph[$j]->lb('reset');

   foreach my $i (1..4) {
     $graph[$j]->lb(new Label(2*$i,-.1,2*$i,'black','center','top'));
     $graph[$j]->lb(new Label(-2*$i,-.1,-2*$i,'black','center','top'));
     $graph[$j]->lb(new Label(-.1,2*$i,2*$i,'black','right','middle'));
     $graph[$j]->lb(new Label(-.1,-2*$i,-2*$i,'black','right','middle'));
   }

 $graph[$j]->lb(new Label(4.8,-0.1,"x",'black','right','top'));
 $graph[$j]->lb(new Label(-.1,4.8,"y",'black','right','top'));

}

foreach my $i (0..8) {
  $a[$i] = random(2,4,1);
}

$f[0] = "y = x - $a[0]";
plot_functions($graph[0],
"x-$a[0] for x in <-10,10> using color:blue and weight:3",
);

$f[1] = "-$a[1] x + $a[2] = y";
plot_functions($graph[1],
"-$a[1]*x+$a[2] for x in <-10,10>  using color:blue and weight:3",
);

$f[2] = "$a[3] = y";
plot_functions($graph[2],
"$a[3] for x in <-10,10> using color:blue and weight:3",
);

$f[3] = "y = -$a[4] x - $a[5]";
plot_functions($graph[3],
"-$a[4]*x-$a[5] for x in <-10,10>  using color:blue and weight:3",
);

$f[4] = "y = x + $a[6]";
plot_functions($graph[4],
"x+$a[6] for x in <-10,10> using color:blue and weight:3",
);

$f[5] = "y = \frac{x}{$a[7]}";
plot_functions($graph[5],
"x/$a[7] for x in <-10,10> using color:blue and weight:3",
);

$f[6] = "$a[8] = x";
$graph[6]->moveTo($a[8],-10);
$graph[6]->lineTo($a[8],10,'blue',3);


###############################################
#  Create figures that can be inserted directly
#
foreach $j (0..6) {
  $fig[$j] = image(insertGraph($graph[$j]), 
  width => 150, height => 150, tex_size => 200);
}

BEGIN_TEXT
$fig[0]
END_TEXT

ENDDOCUMENT();        

[goehle]

Note: I made an edit above. I figured out what I was doing wrong with mathobjects and how to use them properly in RadioButtons. I'm still having trouble with graphs though. Also, when I print to hard copy the math mode text isn't rendered correctly. I get things like:

In particular you'll notice the unrendered math next to the bullets and the HTML appearing in the correct answer area.

[dpvc]

I figured out what I was doing wrong with mathobjects and how to use them properly in RadioButtons.

Excellent.

Also, when I print to hard copy the math mode text isn't rendered correctly.

This is a flaw in handling of student and correct answers the hardcopy module of WeBWorK itself. The answers are put into verbatim mode, so even if they include TeX code, that code is displayed verbatim. I don't know if the hardcopy module actually calls the problem to get an AnswerHash (I think it must to get the correct answers) or simply uses the student answers from the database, but if it gets an AnswerHash, it should use the student_latex_string (or whatever it is called) from the answer hash for the student answer, if that is available, and the verbatim student_ans otherwise. Similarly correct answers should come from correct_ans_latex_string if available. That would allow you to show math as the correct answer. But as it stands, there is no way for the radio buttons to get around the verbatim mode that is used in the hardcopy answers.

The reason the HTML is showing up in the correct answers is again because of the flaw in the hardcopy generator. The string that is being used is the correct_ans string from the AnswerHash, but that is actually an HTML string, because that is what is used in the results table for the correct answer. Most of the time there is no special HTML in the correct_ans, but the String object has to protect any HTML special characters, and the code to do that will show up verbatim in the correct answer output of hardcopy.

The real source of the problem is that AnswerHash really should have correct_ans, correct_ans_latex and correct_ans_html fields rather than using correct_ans for both HTML and plain text strings. Similarly, there should be student_ans, student_ans_latex and student_ans_html. The results table would use student_ans_html and correct_ans_html (and default to escaped versions of student_ans and correct_ans if those aren't available), and hardcopy would use either student_ans_latex or student_ans in verbatim, and correct_ans_latex or correct_ans in verbatim. The fact that there is no clear separation between the roles of plain text, HTML, and LaTeX is a source of a number of problems like this. No one knows what fields have what type of escaping in them.

Because the correct answers needed to show up correctly in the results table, I was forced to HTML escape the plain text strings that are used in the table. That has the adverse affect of having the HTML show up in hardcopy (which uses the supposed plain text answers even when LaTeX versions are available). There is no way around that in the current hardcopy generator.

As far as the radio buttons go, you will find a similar problem when you view the student answers if there is math in the radio button choice. This is because the "Entered" column is supposed to be text, not formatted math, and the formatted math one is being handled as a String, and strings don't contain formatted math. While it would be potentially possible to breaking out of the verbatim mode if math is present in the button choice, it was not clear what should be done with the "entered" column, so I didn't do that.

Note that the documentation suggests that you use labels (and displayLabels) when there is math in the radio buttons. This would make the correct and student answers be things like "A", "B", etc, which will print well both in the results table and the hardcopy.

[goehle]

So it seems like the correct answers thing should be fixed by using labels. This is appropriate since if you have mathobjects as the display strings then the correct answers end up as stuff like \($f\) even in html mode. So labels should be used there too.

What about the actual radio button rendering, though? Why is the text to the left of the radio buttons in verbatim?

[goehle]

I tried switching over to labels and displayLabels and those aren't printing well either. (They also have verbatim strings in hardcopy).

Maybe the solution isn't to put html in the correct answer string. The issue is that the results table tries to render almost everything in math mode. However, it does pay some attention to the type of answer. For example, it doesn't put essay question answers in math mode. How about adding code to the results table which outputs some problem types (e.g. string, radio buttons, etc...) without trying to have them rendered? (I.E. add additional answer types here: https://github.com/openwebwork/webwork2/blob/master/lib/WeBWorK/ContentGenerator/Problem.pm#L426 and again in previewCorrectAnswer)

[dpvc]

The big issue is that something is broken with string that is breaking some normal functionality.

This turns out to be due to parserRadioButtons.pl loading contextString.pl, and the latter file sets the context to Context("String") automatically. That was the case with some of the early context files, but it turned out to be bad practice, since it makes loading those files into other macro files harder (as in this case). So I've discontinued doing that, but the old files still do it.

Once that context is set, the only valid MathObjects in that context are the strings (and there are none initially), so the first attempt to create a MathObject in that context will fail. I didn't notice this during my testing because I didn't create any other MathObjects, so never got the message.

I have removed the use of contextString.pl to avoid this.

I can't get the checked or forceLabel options to do anything. In particular if checked is set, the radio button doesn't start checked, and forceLabel doesn't cause empty labels to appear if no labels are set.

The checked option was broken, and I have fixed it. Sorry about that. The forceLabel issue was a documentation error (it should be forceLabels not forceLabel), and the documentation was not clear on what it actually does, so I've rewritten it to (I hope) clarify that. In particular, displayLabels has to be set for it to do anything, since it is only about the printing of the labelFormat as part of the choice text. To make this more clear, I've renamed the option to be forceLabelFormat instead.

I've also changed the default for displayLabels to be 1 rather than 0, as I suspect that the use of labels=>"ABC" or labels=>"123" (where you want displayLabels to be set) will be more common than the use of individual labels to improve the results table output (where you want displayLabels=>0). I've also added a new example in my initial post to cover this case.

The change in displayLabels is probably not backward compatible with the defaults of the older version, but because labels were not working properly there anyway, that may not be an issue. But if people added their own labels int eh choice text itself, this might mean that there will be double labels in those problems. Probably to a big deal.

The maxLabelSize option doesn't work properly. If I set longish labels and set maxLabelSize to 3, I get string concatenation warnings and the student answers are the full long label with some extra ...'s.

The maxLabelSize is only approximate (as indicated in the documentation). The algorithm always uses full words on either end, so there need to be word boundaries in the label before it will have any effect. I've modified the algorithm to work a little better, and to avoid the concatenation warnings (which came from there being an odd number of words).

f you have mathobjects as the display strings then the correct answers end up as stuff like \($f\) even in html mode.

That depends on how you set up your initial choices. I'm assuming you did something like

$f = Formula("(x+1)/(x-1)");
$radio = RadioButtons(['\($f\)','Choice 2'],0);
Context()->texStrings;
BEGIN_TEXT
\{$radio->buttons\}
END_TEXT
Context()->normalStrings;
ANS($radio->cmp);

This works because the first choice is the literal string \($f\) as you point out, and then in BEGIN_TEXT/END_TEXT, the command substitution is done first, which inserts the \($f\) into the output, and then variable substitution is performed, at which point the MathObject $f uses its TeX version (since texStrings are in effect), and finally LaTeX math is processed.

On the other hand, you could do several other things. One would be

$f = Formula("(x+1)/(x-1)");
Context()->texStrings;
$radio = RadioButtons(["\($f\)","Choice 2"],0);
BEGIN_TEXT
\{$radio->buttons\}
END_TEXT
Context()->normalStrings;
ANS($radio->cmp);

where the texStrings are in effect when the menu is created, so the $f will insert its TeX version into the menu itself. That makes the first choice \(\frac{x+1}{x-1}\). You still want to use labels in this case, because this is not particularly nice to look at, either.

Or you could do

$f = Formula("(x+1)/(x-1)");
$radio = RadioButtons(["\(".$f->TeX."\)","Choice 2"],0);
BEGIN_TEXT
\{$radio->buttons\}
END_TEXT
ANS($radio->cmp);

to get the same result (but again labels would be useful).

Finally, you could do something like

$f = Formula("(x+1)/(x-1)");
$radio = RadioButtons([{$f->string => "\(".$f->TeX."\)"},"Choice 2"],0,displayLabels=>0);
BEGIN_TEXT
\{$radio->buttons\}
END_TEXT
ANS($radio->cmp);

to get a label that formats better in the results table but a choice text that formats nicely within the problem.

I suppose that another solution to the problem of how to handle math would be to have the "Entered" column of the results table show something like "Button 1" while the "Preview" column shows the actual choice text (with math displayed as typeset math). That would avoid having the \(...\) show up in the student answers.

Why is the text to the left of the radio buttons in verbatim?

I'm not sure I understand the text you are referring to. Can you give a specific example?

I tried switching over to labels and displayLabels and those aren't printing well either. (They also have verbatim strings in hardcopy).

I changed the escaping code to be more dependent on the dsplayMode, so HTML escaping isn't done in hardcopy mode, and did some other things to make the hardcopy output work better. I still think the hardcopy output should be fixed to use student_latex_string and correct_and_latex_string when these are available rather than always using original_student_ans and correct_ans in verbatim mode, but perhaps that is a matter of preference.

Maybe the solution isn't to put html in the correct answer string.

For screen output, you have to if you want to allow the output to include things like < (which we do, since people want to make radio buttons for things like x < 1).

The issue is that the results table tries to render almost everything in math mode.

That's not a problem, because there is student_ans_latex_string and correct_ans_latex_string that are used for the TeX output. The real issue is the HTML output, not the math output. That is because correct_ans and student_ans are used for the HTML output, but are also used as plain text for hardcopy output, and that is not compatible. The lack of separation between the HTML string and the plain text string is the real problem. That is why I suggested that having student_html_string and correct_ans_html_string would be the appropriate solution. Then you know that student_ans_latex_string is always LaTeX, student_ans_html_string is always HTML, and student_ans is always plain text, regardless of the displayMode. AS it is now, these are dependent on the display mode, and that means you can't really count on them being consistent. So in screen mode, for example, you don't have a reliable plain text version of the correct answer.

How about adding code to the results table which outputs some problem types (e.g. string, radio buttons, etc...) without trying to have them rendered?

I think that is a bad idea, in general. You don't want the webwork2 code (like the code that creates the results table) having to know any specifics about the PG code (like MathObjects). This also means you have lots of special cases to worry about that have to be handled in all the places that rendering might be done. It also makes is harder to make new classes that behave like these ones, as that requires system-level changes in webwork2 rather than just additional macro files in PG.

If you wanted to add an AnswerHash property that controlled how the results table handles the student and correct answers, that might be useful.

In any case, its' not really there results table that is the problem, it is the hardcopy handling of student and correct answers that is the real problem. There is no reasonable way to avoid its use of verbatim, when it would be perfectly possible for it to use the latex strings that are available in the AnswerHash instead.

[goehle]

Thanks for getting to this so quickly.

I'm able to use MathObjects now and the options behave as you describe. Now almost all of my examples work. The one that doesn't is pushing boundaries a bit, so if its too much you can say its unsupported. If I try to view the hardcopy of the following problem I get the error

Failed to convert TeX to PDF with command 'cd /opt/webwork/webwork2/htdocs/tmp/TestCourse/hardcopy/work.dZarjaLo && /usr/bin/pdflatex >pdflatex.stdout 2>pdflatex.stderr hardcopy' (exit=1 signal=0 core=0).

The HTML works just fine.

DOCUMENT();      
loadMacros(
   "PGstandard.pl",
   "MathObjects.pl",
);
loadMacros(
"parserRadioButtons.pl",
"PGgraphmacros.pl",
"unionTables.pl",
);

TEXT(beginproblem());
foreach my $j (0..6) {

 $graph[$j] = init_graph(-5,-5,5,5,'axes'=>[0,0],
              'ticks'=>[10,10],'size'=>[300,300]);
 $graph[$j]->lb('reset');

   foreach my $i (1..4) {
     $graph[$j]->lb(new Label(2*$i,-.1,2*$i,'black','center','top'));
     $graph[$j]->lb(new Label(-2*$i,-.1,-2*$i,'black','center','top'));
     $graph[$j]->lb(new Label(-.1,2*$i,2*$i,'black','right','middle'));
     $graph[$j]->lb(new Label(-.1,-2*$i,-2*$i,'black','right','middle'));
   }

 $graph[$j]->lb(new Label(4.8,-0.1,"x",'black','right','top'));
 $graph[$j]->lb(new Label(-.1,4.8,"y",'black','right','top'));

}

foreach my $i (0..8) {
  $a[$i] = random(2,4,1);
}

$f[0] = "y = x - $a[0]";
plot_functions($graph[0],
"x-$a[0] for x in <-10,10> using color:blue and weight:3",
);

$f[1] = "-$a[1] x + $a[2] = y";
plot_functions($graph[1],
"-$a[1]*x+$a[2] for x in <-10,10>  using color:blue and weight:3",
);

$f[2] = "$a[3] = y";
plot_functions($graph[2],
"$a[3] for x in <-10,10> using color:blue and weight:3",
);

$f[3] = "y = -$a[4] x - $a[5]";
plot_functions($graph[3],
"-$a[4]*x-$a[5] for x in <-10,10>  using color:blue and weight:3",
);


###############################################
#  Create figures that can be inserted directly
#
foreach $j (0..6) {
  $fig[$j] = image(insertGraph($graph[$j]), 
  width => 150, height => 150, tex_size => 200);
}

$radio = RadioButtons(['$fig[0]','$fig[1]','$fig[2]','$fig[3]'],0,labels=>'123',checked=>2);

BEGIN_TEXT
\{$radio->buttons\}
END_TEXT

ANS($radio->cmp);
ENDDOCUMENT();        

As for hardcopies, I'm still seeing verbatim for the actual radio options themselves, not just the answers.

The correct answer and student answer strings look a lot better. There are still issues if have complicated options and don't use lables, but I'm willing to live with that since you have similar issues on the HTML side. Your comments about using the latex strings in the hardcopy mode are similar to some things Danny Glin was saying. Mike seemed to feel that the strings were the unmodified student answers for a reason. It could be changed though.

What you said before about how there should be a "html" output in addition to a "string" and "TeX" output strikes me as really good advice. Unfortunately we don't have that and its getting to the point that not everything in an answer is mathematics. (Essay questions and some some python output for cs problems I'm testing, in my case.) So if you always put student_ans in an equation rendering mode you either get weirdly formatted pyton output (for example) or you have to immediately escape out of mathmode somehow from within PG, which seems a bit hacky. So it seems like some post processing on the ww2 side is inevitable, unless we change PG so it returns the "right" thing. Maybe I'm not understanding it though. If it really is bad practice then there are some things that I'll need to change since I"ve been putting that kind of check in the attempts table for essay answers and for formatting student answers in the Past Answers page.

If the screenshot is actually correct then everything thing seems fine with this pull, otherwise I'll let you deal with that.

[dpvc]

Well, it turns out that this is (once again) the difficulty of not knowing what has been escaped and what hasn't. When you use things like '$fig[0]' for the choices, the radio button thinks the choice is the literal text $fig[0], and it used \verb to protect that for TeX output; however, when the radio buttons are later inserted into BEGIN_TEXT/END_TEXT using \{...\}, the $fig[0] is inserted into the output string, and since variable substitution is done after command substitution in BEGIN_TEXT/END_TEXT, the figure is put into the output later by BEGIN_TEXT/END_TEXT (without the radio button knowing about it). The actual value of the $fig[0] variable includes a newline, and that is not allowed in \verb, which is why TeX is complaining. The radio button object doesn't know that you are using its output in BEGIN_TEXT/END_TEXT, so can't know to so anything different to the output to make it work in that context; similarly, BEGIN_TEXT/END_TEXT doesn't know that the result is not supposed to be processed further, and so does the string substitution on it anyway.

I had intended to make it possible to use the choice text as verbatim text (so that you didn't have to worry about things like % or _ or < in the menu choices without worrying about it. But that meant that you couldn't do math mode in the choices; you now want to do variable substitution as well. So it looks like I can't protect the choice text, and will have to have the page author be responsible for handling special characters.

That has at least one adverse consequence (in addition to the positive ones of allowing math mode and variable substitution). The choice text gets used in the radio buttons in three distinct ways: as text within the page listing the button choices, as the string answers entered by students in the "Entered" column of the results table (and the correct answer popover), and as LaTeX versions of the student and correct answers in the entered table.

Unfortunately, math and things like images can't be used in the results table very easily, and macros for handling the special characters like $ and % will only produce the correct result for one of the three places that the choice text gets used. So if the choice text is allowed to include arbitrary formatting, which is what is needed to handle math and images and special characters, then that means the text can't be used easily for the student and correct answers.

The labels option can be used to get around this, but it is somewhat awkward and the situations where you need it are more extensive than I had originally thought. So I need to think further about what is the best solution to the problem. I suspect that it means that the radio buttons should not use the choice text as the labels unless you explicitly ask it to (or perhaps if it finds that there are no special characters in the text). So the default might be to use "Button 1", "Button 2", etc. in that case.

In any case, I'll have to remove the protection of the choice text and leave that in the hands of the problem author. Sigh. I'll think about the label situation and make another commit when I figure out the course to take.

[goehle]

If the choices are going to support complicated text then I think you are right, the labels should be shown and used by default unless choices is explicitly set. Even if you could get the choices working in the student answer and correct answer it would look bad. I think this is the same issue I was having with the math I put in the image above. The math is coming from a MathObject which was a variable substitution. (Perhaps if I had explicitly gotten the TeX from the object it would have worked?) So fixing images will fix my other issue.

If this all seems like too much, the correct answer may be that variable substitution isn't supported in radio buttons. That's not a completely unreasonable approach. I could probably have figured out ways to code both of my problems to avoid it. However, if this is the solution then it would probably be best to have RadioButtons keep the variables from being substituted at all (i.e. not within the main problem text). Then it will be more clear to problem authors that they will need to get their values into the RadioButton object another way.

[dpvc]

OK, I think I have it worked out now. You can use math, images, etc. in the choice text, and if you do, then the RadioButtons will use "Choice 1", "Choice 2", etc., as the labels unless you override that with your own labels. If the choice text can be used safely for the answers, they will be used (this is for backward compatibility mainly). You can force the choice text to be used by using labels=>"text".

I have updated the documentation it reflect the new situation.

@goehle, thanks for all your work in testing this. As always, the thoroughness of your testing has been a big help.

[goehle]

Sorry I didn't get to this earlier. I've been juggling lots of stuff. One very last thing, and feel free to say its not going to come up. When I test the example you posted above,

$radio2 = RadioButtons(['"><b>$%{}_^~x<x ','math: \(x+1\)','Button3'],0, labels=>'abc',displayLabels=>1);

I get ! Missing } inserted. in hardcopy mode. Is there something I should do to put those characters into verbatim with the changes?

[dpvc]

The original example no longer applies, because we are no longer protecting special characters in the menu choices. So if you want the menu choice to include literal < or % or { or other special characters, you will need to use the PG macros for them (when appropriate) or roll your own. That is the cost of allowing math and images and other such items in the choices. The RadioButton() if the characters are supposed to be protected, or if they are the actual characters you want inserted into the output. And if you put the output of its buttons() method into BEGIN_TEXT/END_TEXT, it can't prevent BEGIN_TEXT/END_TEXT from substituting commands/variables/math in its output without additional protection. The buttons() method doesn't know whether that additional protection is needed or not because it can't tell where its output is to be used.

I should remove (or modify) the original example.

[goehle]

I figured it was something like this. I think the extra utility of having math and images in the radio buttons is worth the cost, and as you said, there are macros for including those special characters.

[dpvc]

I agree. The end result is better than the original pull request. Thanks for the help.