Problems with the plug-in are pretty much evident from the notes on the
page:
- Mozilla and Amaya are the only browsers that currently implement MathML.
- Mozilla before 1.4 on Linux gives you a bit of a run-around before it will render the math.
- TWiki's occasionally dubious and often outright rebellious XHTML compliance can cause trouble in the browser. This is the root of my raising the bug MinorXHTMLNonComplianceInTemplates We need a Wiki'fied version of HTML Tidy.
After XHTML clean-ups on my own installation, though, the plug-in works.
It fills a very old, very annoying gap in my document management
strategy.
--
SimonClift - 22 Apr 2003
OK, I've come up with a less drastic way of getting the content type
out to the browser. I've modified the
lib/TWiki.pm and the
lib/TWiki/Plugins.pm
modules to create a plug-in content type subroutine, called during the
sub writeHeaderFull routine.
The diffs are against
TWiki.pm
526a527
> $contentType = &TWiki::Plugins::pluginContentType( $pageType, $contentType ) || $contentType;
and against
lib/TWiki/Plugins.pm
45a46
> 'pluginContentType', # ( $query ) 1.020
52a54
> 'pluginContentType' => 1,
375a378,385
> sub pluginContentType
> {
> # Called by TWiki::writeHeader
> unshift @_, ( 'pluginContentType' );
> return &applyHandlers;
> }
>
> # =========================
So I've added another routine to the Plugin interface. Is this bad?
If this is not a bad thing then I'll upload the changed plugin.
--
SimonClift - 28 Apr 2003
I should note that the currently uploaded plug-in
does not support this
solution. I've also just tested the plug-in against the latest
TWikiBetaRelease and it works fine, but the changes to TWiki.pm and
to Plugins.pm are a little different. I'll tidy up my notes and upload
the changes during the next few days.
--
SimonClift - 19 Jul 2004
Simon, you should be aware that recently a patch to make
writeHeaderFull provide different content went into the core code. If the 'apptype' parameter is provided to the edit function then that will be put into the header. See
EnableProgrammableApplicationType. The right way to handle your change above is to extend this to the view and preview scripts as well, I think. Your first core patch?
--
CrawfordCurrie - 19 Jul 2004
I started implementing
EnableProgrammableApplicationType for View and Preview as well, and I get the feeling this is
not a better solution. For example, about rdiff? There are just too many places the change would need to be made when configuring the system, compared to the nice one place with the Plugin call. It seems to me that the plugin setting needs to change the
default ContentType, and
EnableProgrammableApplicationType needs to be able to overwrite what the plugin asks for. This should work (in writeHeaderFull):
$contentType = (($pageType ne 'edit') && &TWiki::Plugins::pluginContentType( $pageType, $contentType )) || $contentType;
--
JonathanGraehl - 04 Aug 2004
.zip checked into
CVSplugins:LaTeXToMathMLPlugin
--
WillNorris - 24 Nov 2004
Noted, thanks. Bringing this up to date is on my New Year's Resolution list...
--
SimonClift - 21 Dec 2004
For a comparison of this plugin with other math related plugins, please see
ComparisonMathLatexPlugins.
--
AmandaSmith - 01 Mar 2006
Think link given for the windows excutable of itex2mml
http://golem.ph.utexas.edu/~distler/blog/archives/000319.html
no longer has the windows executable. I've been reading the source to see if I could figure out to compile it and I am gaining some understanding on how the software is built:
http://twiki.org/cgi-bin/view/Support/SID-00428
--
JohnCreighton - 2009-07-22
I tried out this plugin. It delivered TML code twice. Looking at the code it could not work, for example,
outsidePREHandler was returning
$_[0]. I fixed the code and tested it out. The plugin delivers the proper output of the itex2MML script. However, it did not work, even by setting the DOCTYPE the same way as the
MathML Torture Test
page. Anyone cares to debug?
--
PeterThoeny - 2011-03-18