Tips on debugging mathematics filter
| Project: | Mathematics Filter |
| Version: | 5.x-1.0.x-dev |
| Component: | Miscellaneous |
| Category: | support request |
| Priority: | normal |
| Assigned: | dwees |
| Status: | postponed (maintainer needs more info) |
Jump to:
1. On my Drupal 5.1, Filtered HTML deletes the style attribute of the IFRAME that [graph] needs, and the iframe ends up cutting off the graphic because there's no sizing information. This doesn't happen with Full HTML. (I don't know how to turn control Filtered HTML's behavior, unfortunately. I'd expect a checkbox on the filter page, but it's not there.)
2. Note that the TeX filter uses the mimetex engine, stored where the server can find it (for example, in cgi-bin). However, the graph filter users Walter Zorn’s JavaScript graph library, stored in mathfilter/js. So, if the module is properly configured for [tex], it may not be for [graph], and vice versa.
3. If you want to make sure that the mimetex engine is being called from inside Drupal try something like this:
<img src="cgi-bin/mimetex.cgi?f(x)=\int_{-\infty}^xe^{-t^2}dt" />But make sure that the paths in admin/settings/mathbuilder are configured for whatever works in this test.
4. I put anything with square bracket tags (mathfilter, mapbuilder) highest on the filter list (like -10). And I put linebreak and smarkypants lowest (like 10). Then HTML goes in the middle. That strategy seems to work OK, since the square bracket tags should be converted to HTML before any other HTML is generated.
Maybe this would be useful for the documentation. I don't know.
#1
I'll add your information to the documentation, although the most recent version includes some information about the filter_html filter not working with the [graph /] tags.
Dave
#2
No one has reported any problems in this area since this report, so I'm closing this issue.
#3
1 is not an issue with filter html, it's an issue with mathfilter itself.
In mathfilter_filter(), case 'prepare': doesn't have a 'break;' and as such there is a "fall through" to case 'process'. Since filter html has its way with the $text /after/ mathfilter, filter html removes all tags it doesn't like e.g. iframe, etc. Simply removing case 'prepare': resolves this issue.
I have a patch that I could submit, but it is entangled in a few other things, one of which isn't completely working. The not completely working one is creating a graph of variable size; it doesn't render the grid properly. Something I wasn't expecting on having so much trouble with.
If you want, I could submit the patch. Fresh eyes could prove beneficial :)
#4
Been thinking a bit about these other issues and have some comments on them as well:
2 Pathing is correct for using js. Nothing beyond proper installation of mathfilter is necessary for this to work properly. The reason for this is that the graph is in an iframe and as such is a separate request to the server. So, the relative links to graphframe.php work just fine. The only thing that must be remembered is that if the graphs get moved out of a iframe to directly in the page then the links to the js must be changed to absolute urls.
3 The only way that the suggested tag would be processed through Drupal is if clean urls are used. If it is then the path would be root'd at the public html root. If clean url is not used, then it would be relative to the page that references it, which is the index.php. Thus it'll hit mimetex.cgi directly entirely side-stepping Drupal. Either way, this input path is relative to the public html root. Both will work.
The only thing that this does is verify that mimetex.cgi itself works.
4 This is pure opinion. It actually doesn't matter one bit what is converted to html first since these tags are in square brackets. It'll work either way, but it is entirely unnecessary to change the order of the what filter gets priority.
#5
Just did some checking and I'm partially wrong about my comment on 3. Regarding going through Drupal with clean urls, I would be right about it being root'd at the public html root and going through Drupal, if the url used was '/cgi-bin...' but above it doesn't have the '/' in front.
So, this img would work if the page was directly off root e.g. /home, but would fail if it was deeper in e.g. /home/page/deeper/in. On this last example the full path generated by the img tag would be /home/page/deeper/cgi-bin/mimetex.cgi?.... See: http://drupal.org/node/120621
Please note that if url aliasing is off, this will also fail unless the server is setup to have the cgi-bin directory off of /node. Or unless that '/' is put in.
#6
I'm reopening this issue as obviously it needs more discussion. If you could include your partial patch that would be cool.
Dave