My colleague noticed that he could use ASCIIMathML to graph in WeBWorK, and the graphs are much cleaner than with PGgraphmacros. Has anyone tried this before? If you are used to PGgraphmacros.pl, try the code attached. I was impressed when I first saw it.
So far we have identified these issues:
- Internet Explorer requires a plugin for it to work
- Double-clicking on a graph reveals some code that generated it. For some problems, I may wish to hide the function's rule from students.
- Graphs don't compile in the library browser, but compile fine in the real problem.
Can anyone point out more problems (and hopefully solutions too) to using ASCIIMathML for graphing like this? Next year I plan to start work on a library of problems for PCC, and I'd really like to use this instead of PGgraphmacros if the problems can be overcome.
The example is attached. More graphing commands are near the bottom of http://mathcs.chapman.edu/~jipsen/math/pub/ASCIIMathML/ASCIIMathML.js.
I suspect you will not be able to get hardcopy output of these graphs (other than printing the individual problems from the browser). That would be a show-stopper for me.
One of the reasons that WeBWorK uses macro libraries is so that there is a layer of interface between WeBWorK at the actual output. That makes it possible to to have the same input drive several different kinds of output (e.g., screen versus hardcopy). Your example problem relies on running javascript in the browser (and also relies on having network access in order to load the ASCIIMathML library), which is not something that will work when producing the PDF output via pdflatex, as WeBWork currently does. (On the other hand, perhaps there is a TeX implementation of the ASCIIMathML graph environment, I don't know and didn't check.)
ASCIIMathML produces SVG graphics, which (as you say) are quite nice. Perhaps a better approach would be to make the PGgraphmacros output SVG graphs rather than images (or make a new macro package that does that). They certainly are due for an update.
Davide
One of the reasons that WeBWorK uses macro libraries is so that there is a layer of interface between WeBWorK at the actual output. That makes it possible to to have the same input drive several different kinds of output (e.g., screen versus hardcopy). Your example problem relies on running javascript in the browser (and also relies on having network access in order to load the ASCIIMathML library), which is not something that will work when producing the PDF output via pdflatex, as WeBWork currently does. (On the other hand, perhaps there is a TeX implementation of the ASCIIMathML graph environment, I don't know and didn't check.)
ASCIIMathML produces SVG graphics, which (as you say) are quite nice. Perhaps a better approach would be to make the PGgraphmacros output SVG graphs rather than images (or make a new macro package that does that). They certainly are due for an update.
Davide
Supporting SVG graphics from WWPlot has been on a back burner for some time. WWPlot is a math specific front end for GD and gdlib which can produce PNG, GIF and JPEG formats. (I don't believe the last is currently enabled in WWPlot.)
There is a CPAN module: http://search.cpan.org/~twh/GD-SVG-0.33/SVG.pm
that could probably be used to add an SVG output capability to WWPlot.
Separately -- the front end of PGgraphmacros could also use an update, or as Davide says, a replacement. It was written somewhere around 1998-1999 and many of the constraints of that time no longer exist.
There is a CPAN module: http://search.cpan.org/~twh/GD-SVG-0.33/SVG.pm
that could probably be used to add an SVG output capability to WWPlot.
Separately -- the front end of PGgraphmacros could also use an update, or as Davide says, a replacement. It was written somewhere around 1998-1999 and many of the constraints of that time no longer exist.
Ah yes, no hard copies is a deal breaker. Thanks for the information you two.