The Process_jsMath span

The Process_jsMath span

by Gustav W Delius -
Number of replies: 5
This is a bit of a technical post.

The current jsmath filter puts a <span id="Process_jsMath"></span> in front of each bit of filtered text even though only a single such span is required. This makes the page source look very ugly, because I am filtering all strings so that there are very many of these spans indeed. It also leads to a lot of warnings from my firefox tidy extension because one is not supposed to have several spans with the same id.

I therefore took this out of the jsmath filter and instead printed a single <span id="Process_jsMath"></span> in the print_footer() function. This seems to work well, even on pages which don't have any maths the <span id="Process_jsMath"></span> does not appear to do any harm.

A more elegant solution would probably be to leave it in the responsibility of the filter to provide a <span id="Process_jsMath"></span> but make the filter intelligent enough so that it supplies only one.

On a related matter: when one turns off the processing of <tex> tags then the filter also stops inserting the <span id="Process_jsMath"></span> and no processing takes place, even when there are \( , $, or similar in the text.
Average of ratings: -
In reply to Gustav W Delius

Re: The Process_jsMath span

by Davide Cervone -
I admit that this "Process_jsMath" tag is a bit of a kludge, but since Moodle doesn't have a means for filters to add text to the top or bottom of the page (or at least didn't in version 1.5; I haven't looked at 1.6), there was no easy way of telling jsMath whether the filter was active or not. Note that the filter's javascript.php will be shipped to the user regardless of whether the filter is active in the admin configuration panel or not, so jsMath needs some way to tell if it is active, and the presence of that SPAN tag is the method I used.

This makes the page source look very ugly, because I am filtering all strings so that there are very many of these spans indeed.

Machine-generated source frequently is. I don't see this as a real problem unless you are planning to save the pages for hand editing in another venue. Do you really think this is a serious concern?

It also leads to a lot of warnings from my firefox tidy extension because one is not supposed to have several spans with the same id.

Well, you asked for those messages by installing the extension. smile

I know that ID's are supposed to be unique, but it is very easy to check for the presence of a tag with a given ID and not easy to test for other markers (like a tag of a particular class, for example), and since jsMath is already very slow, I didn't want to slow it down by having to look harder for whether it should run in the first place. If you really don't like that, it could be changed to a class and you could scan through all the SPAN's for one with the given marker class. If you have a suggestion for a better way to mark the page and check it easily, I'd be happy to hear it.

A more elegant solution would probably be to leave it in the responsibility of the filter to provide a but make the filter intelligent enough so that it supplies only one.

I don't think this is going to be possible. Since Moodle caches text that it has already filtered and doesn't call the filter again when it uses the cached version, there is no way for the filter to tell if the page already contains a "Process_jsMath" tag or not. (At least I couldn't think of one.) Because the cached text could be used in a different situation (where there ISN'T a previous marker), each text needs to be marked so that jsMath will know it needs to run.

I admit that this is not ideal, but I could not come up with a way that would work without storing the marker as part of the text, while still allowing you to turn the jsMath filter on and off, without making changes to the Moodle system code. If anyone has a better plan, please let me know. Remember that the filter.php may not run at all (since the text might be cached), the javascript.php file is loaded on every page, even when the jsmath filter is not active, and the javascript.php file is not really a php file, but actually javascript source that is included verbatim in the output of lib/javascript-mod.php so its contents are not generated by the filter on the fly.

I therefore took this out of the jsmath filter and instead printed a single <span id="Process_jsMath"></span> in the print_footer() function. This seems to work well, even on pages which don't have any maths the <span id="Process_jsMath"></span> does not appear to do any harm.

The main consequence of that is that you will not be able to disable jsMath in the admin configuration panel. I don't foresee any other problems.

Davide
In reply to Davide Cervone

Re: The Process_jsMath span

by Gustav W Delius -

Davide,

many thanks for that explanation. I had indeed not thought of the problem with the caching.

I think this makes a very good case for extending the text filter mechanism to allow text filters to add stuff to the footer. I have just created tracker entry MDL-6981 for this.

In reply to Gustav W Delius

Re: The Process_jsMath span

by Davide Cervone -
On a related matter: when one turns off the processing of tags then the filter also stops inserting the <span id="Process_jsMath"></span> and no processing takes place, even when there are \( , $, or similar in the text.

This is a bug, and I have fixed it in jsmath/filter.php in the CVS archive.

Davide
In reply to Davide Cervone

Re: The Process_jsMath span

by A. T. Wyatt -
I found this bit added to each grading comment that I added with the in-line text comments.  I was not using, and have never used, the math tools (although our math instructors like them very much!)

I did not use any characters at all, except a period at the end of the sentence.

I thought this rather odd!

atw
Attachment jsmath.gif
In reply to A. T. Wyatt

Re: The Process_jsMath span

by Gustav W Delius -
Hi atw, that looks like a bug in the grading tool. Moodle should not put text that is to be displayed in a textarea through filters. Please post a bug report in the tracker.