Archive of LatexModePluginDev

Here in lie the discussions on releases prior to v3.0.

-- ScottHoge - 30 Sep 2006

---

Here is space to comment on the LatexModePlugin.

-- ScottHoge - 22 Aug 2005

Congratulations! This was long overdue. I never did understand why Latex2Html had been necessary. Will definitly give it a try, cause it doesn't depend on ImageMagick either (hopefully). I will try it with GraphicsMagick instead, cause I never managed to run ImageMagick properly on Cygwin.

-- FranzJosefSilli - 22 Aug 2005

Scott, congrats on a great release! It works magnificently.

-- JosMaccabiani - 22 Aug 2005

Thanks Scott for contributing this Plugin . Plugins add significant value to the TWiki project.

-- PeterThoeny - 22 Aug 2005

Thanks, all. I'm very impressed with TWiki, and this plugin was the one missing piece my group needed... and a way to contribute back to the project. I hope to add more features in the future, including getting the font color switch working and adding in a latex preamble hook to allow a greater possibility of fonts (e.g. AMS-latex fonts) in rendering.

-- ScottHoge - 23 Aug 2005

OK. New rev uploaded today, with color options and preamble parameters! My goal in the syntax has been to provide enough flexibility that latex pros can do what they want, but still keep the straightforward MathModePlugin interface for those new to latex. Hopefully, this hits the mark.

Update: image scaling is provided as well. This requires a second CPAN package to work: Image::Info.

-- ScottHoge - 05 Sep 2005

i am running debian stable (3.1). i cant get the plugin working. I have removed mathmode plugin, setup the paths to the progs, and now i get this error:

Latex rendering error!! DVI file was not created. at the bottom of my page.

the /tmp/latex.log file shows this
This is e-TeX, Version 3.14159-2.1 (Web2C 7.4.5) entering extended mode
! I can't find file `twiki_math.tex'.
<*> twiki_math.tex
Please type another input file name:
! I can't write on file `texput.log'.
Please type another transcript file name:
! Emergency stop
No pages of output.

-- TerryRankine - 12 Sep 2005

well - dont get me wrong - i played with it for about 2 hrs and AFTER lunch it magicly started working.

I cant tell you why - but i think its something to do with its tempory file storage location. however i now have to thankyou for a working alternative to MathModePlugin

-- TerryRankine - 12 Sep 2005

Terry, by chance I ran into the same thing today installing the plugin on my Dakar alpha machine. In my case it was a permissions problem: I unzipped that ZIP file as root, but apache runs as 'nobody' and could not write the .dvi file to the pub directory. The next release should fix this, or at least fail more gracefully on permissions errors.

-- ScottHoge - 12 Sep 2005

In the interest of better TWiki security, I've updated the plugin. Some parameters were passed to a shell, leaving an open hole similar to TWiki:Codev.SecurityAlertExecuteCommandsWithInclude. These parameters are now scrubbed before passing. I believe that convert is cranky enough about the input syntax to render the risk of an attack quite low... the attack would have to survive convert parameter parsing. Nonetheless, it's best to close the hole.

-- ScottHoge - 30 Sep 2005

FYI. Latest version (2.1) is both Cairo and Dakar compatible.

-- ScottHoge - 30 Sep 2005

Hi Scott (or anyone else willing to take this on)

the new WysiwygPlugin is starting to become so nice that it might be worth switching editors. Unfortunately, LatexModePlugin doesn't work well together with the Wysiwyg plugin.

see: WysiwygPluginProblemReports

Since I'm not a developer I can't guess at the amount of work it would be to find a working solution, and if that solutions would be in this plugin or in the WysiwygPlugin. It would be a shame to lose the simplicity of the standard %$ latex math delimiters.

Of course I'd be happy to help (test) in any way I can, should you be interested to investigate this further!

Cheers,

-- JosMaccabiani - 30 Oct 2005

Ooops, sorry, version 0.16 of WysiwygPlugin seems to have fixed this issue. Please ignore

-- JosMaccabiani - 30 Oct 2005

Scott, I made some small changes to the Plugin topic, feel free to take it into the next release:

• Do not link to itself
• Use term "topic" instead of "page" in SHORTDESCRIPTION
• Use Interwiki links for TWiki.org topics

-- PeterThoeny - 12 Nov 2005

There are two fairly embarrassing bugs in (at least) the last release, in regards to table handling:
LatexModePlugin.pm, L344: should read:

             $txt2 .= sprintf($cpfrmt."\n",$env,$tbl,$opts{'caption'}).

and the following line should be inserted between L263 and L264 of LatexModePlugin.pm:

             $txt = '<a href="#'.$ref.'">'.$backref.'</a>';

My apologies. I'll wrap these into the next release.

-- ScottHoge - 14 Nov 2005

Why is it that LatexModePlugin does not render the Latex example? I have the same problem with my installation.

-- DenisPerretGallix - 27 Nov 2005

It does not render on TWiki.org because this Plugin is not installed here. Try TWikiDebugging.

-- PeterThoeny - 27 Nov 2005

Thank you Peter for pointer

-- DenisPerretGallix - 27 Nov 2005

Scott, your great Plugin does not provide a MANIFEST file for proper use with Dakars pseudo-install mechanism. Should I file an appropriate bug item at develop?

-- FranzJosefSilli - 12 Dec 2005

Franz, feel free to add this to the SVN tree. I probably won't be able to fix it until next month.

-- ScottHoge - 19 Dec 2005

Great Plugin! I've been using the MathModePlugin under the Beijing release under Mac OS X Jaguar on an early XServe and have been moving some activity to Cairo running under Mac OS X Tiger on a stock Mini (sweeet, quiet little box). After many hours, finally successfully installed under Mac OS X Tiger.

In the plugin code itself I had to edit:

• $PATHTO* variables
  • The docs are pretty cryptic here. Is this the intended interface or are there secret Set possibilities available?
    • This interface is new in the TWiki:Plugins.Dakar release. In Dakar, there is a separate LocalSite.cfg file where these can be declared, allowing one to update the perl code without forcing one to redo the configuration with each update. -- SH
• $pathSep had to be set explicitly to /
  • images were being created at the same level as the intended destination directory with \ in the filenames!!
    • this is due to my own ignorance, having never worked with Mac's. What does the

      $^O

      variable return on a Mac? This can be solved by a simple switch. -- SH
    • As reported below it yields darwin. Following on to the switch you had, this works as a replacement line on my installation:
      my $pathSep = ($^O =~ m/(linux|Unux|darwin)$/i) ? '/' : "\\" ; # N.B. darwin = Mac OS X
      Note: I suspect you really want Unix rather than Unux as the switch in your code (and my echo of it above) would suggest, though I don't know what all variant spellings might be used to avoid (tm) issues. -- DF
• $cmd for convert changed from just -trim to -trim +repage
  • typical symptom was correct-size white image which, when viewed in its own window, was huge with rendered LaTeX in the middle.
  • why? images were created and trimmed, but the canvas remained larger than the image
  • the +repage option (??new in ImageMagick 6.x??) resizes the canvas The +repage command is new to me. (and the ever-changing ImageMagick API is one of the reasons the GraphicsMagick project was created.) -- SH

The convert utility worked from the shell, but failed with a delegates error when run from within the plugin. The fix:

• edit explicit path to gs in delegates.xml one of ImageMagic's config files: lib/.../config/delegates.xml
  • Thanks for noting this. -- SH

I suspect a minimal path is supplied to convert running under TWiki. TWiki complained (as it should) about my initial attempt to add /usr/local/bin to its safe path. Chasing down place to tell convert was quite an escapade

N.B. There remains a problem with the rendering of the example:

%\[\sigma_1 > \sigma_2 > \cdots > \sigma_n \geq 0\]%

which seems to invite the TWiki rendering engine to (properly) translate the greater than signs into entities for the alt tag, but TWiki then goes on to translate the closing bracket of the image tag as well, resulting in invalid html within the div tag.

• Strange. Could this be related to any edits, e.g. using the WYSIWYG editor? -- SH
• As reported below, I'm not using the WYSIWYG editor. Perhaps my report about Codev.VariableExpansionBugInFormattedSearch is relevant. -- DF

One further note:

The plugin code claims that to change the png output format a change must also be made in the latex2html initialization file. I believe this claim is incorrect. I swapped between gif and png in the course of troubleshooting by only making a change in the plugin code. I thought things were independent of latex2html at this point...

• Whoops! The comment was (accidentally) carried over from the TWiki:MathModePlugin comments. latex2html is not used in the plugin. -- SH

-- DickFurnas - 09 Jan 2006

Hi Dick, thanks for the feedback. I've interspersed a few comments above, but to summarize, it looks like a Mac install could use the following:

• include a Mac switch on the PathSep declaration,
• allow additional inputs to the convert command,
• and possibly a work-around for mis-rendering of html entities.

BTW, your feedback means that all major OSs (Linux, Windows, Solaris, Mac) are reported operational!

• Congratulations! -- DF

-- ScottHoge - 09 Jan 2006

Hi Scott, thanks for your comments. Mac OS X is based on an open source variant of BSD Unix developed and supported by Apple and known as Darwin. Here is the result of the query you asked for:

cpan> ! print "$^O"
cpan> darwin

...As to the funky rendering of the closing image tag, I'm not using the WYSIWYG editor. But have seen a couple of other similar rendering problems, in particular the %SEP% variable yields improperly closed span tags at times. It may be a side effect of some other plug-in. I'll try to sort it out and let you know what I find.

-- DickFurnas - 11 Jan 2006

Scott: See what I've posted at Codev.VariableExpansionBugInFormattedSearch for the %SEP% issue. Don't know if it's related. I should also add that in testing on several browsers the image still appears properly and sometimes "does the right thing" with the rendering. If you view source in Firefox, for example the offending image tag appears in red. You might want to see if the problem exists on your installation(s) and merely went unnoticed.

-- DickFurnas - 12 Jan 2006

Hi Scott: For my applications, the heuristics for alignment of in-line graphics are disappointing.

• Agreed. -- SH

Here are some observations:

## orig #            my $algn = ($escaped =~ m/[\_\}\{]|[yjgpq]/) ? 'middle' : 'bottom' ;
## \_ => subscripts \}\{ => heuristic for more intricate expression??   yjgpq => descenders
## nice try for alignment, but pretty sketchy in places:
## e.g. \Sigma \Omega have "g" but nothing below baseline in rendering
## e.g. X^\prime has "p" but no excuse for dropping below baseline.
## e.g. \sum_{i=1}^n  has \_ but nothing below baseline.
##  try variations:
##            my $algn = ($escaped =~ m/\\mbox/) ? 'middle' : 'bottom' ;     
##            my $algn = ($escaped =~ m/[\_]|[yjgpq]/) ? 'middle' : 'bottom' ;
## Stick with this, still pretty bad, but at least visually understandable/consistent:
            my $algn = 'bottom' ;

Perhaps cajole LaTeX into creating a box with white space centered vertically on its impeccable notion of the baseline and use convert to trim to that box?

• This idea is on my radar, but it was lower priority and I just haven't had time to play with it. One possibly I've been thinking of is to render the in-line math within a box of minimum height in latex, trim, and then erode the box away. I'm open to other suggestions as well. (Latex examples, too!) -- SH

-- DickFurnas - 13 Jan 2006

FYI: Forgot to mention that Mac OS X has a wonderful TeX editing environment based on tetex called TeXShop which among other goodies supports immediate rendering to PDF with a clickable pdf which will return you to the associated line in the original TeX file. This thanks to Mac OS X native on-screen rendering support.

-- DickFurnas - 13 Jan 2006

It turns out that a fix for the in-line image rendering was more straightforward than I first thought. I've update the SVN version to my latest changes. I'll wait to give an officail release until after a week or so of testing.

http://svn.twiki.org/svn/twiki/trunk/LatexModePlugin/

-- ScottHoge - 14 Jan 2006

Hi! First of all... thanks for this great plugin!

I have a small problem though: When rendering a large formula, the right side gets cut off:

%$$
Sdgn_{SSA^ -  zuGA} (LC,\Pr ozess,Eigenschaften) = Sdgn_{SSA^ -  } (LC,\Pr ozess,Eigenschaften)*f(LC,\Pr ozess)
$$%

results to the following image:

Is the size of the image configurable somewhere?

-- PeterLohmann - 17 Jan 2006

As luck would have it, the fix for the image alignment problem (i.e. using .eps files instead of .ps) also corrects this latest problem. So, fetch from SVN or wait for the next official release (most likely by Jan 25)

• Fixes now available in Release v2.3 and above. -- SH

-- ScottHoge - 21 Jan 2006

Just installed dakar release, and installed newest version (2.3) of LatexModePlugin. Inline equations have a black background, while ownline equations are fine. My InstalledPlugins page says endRenderingHandler is depreciated - are these related? Anyone else having this problem, or am I doing something wrong?

-- KamArnold - 03 Feb 2006

The endRenderingHandler is included for Cairo compatibility. If running on Dakar, feel free to comment it out.

As for the black-background: very strange. The images are created in the same way (latex->dvips->convert) with a transparent background in both cases. The inline/ownline switch changes only the HTML markup surrounding the image. There may be a css conflict. What software are you running (incl. client browser and OS)?

-- ScottHoge - 03 Feb 2006

The TWiki is running on a Red Hat distribution

The client I had been using is Windows XP Pro with IE 6.0 browser. If I use Firefox (still on a Windows XP Pro machine), everything looks fine.

• There is probably a way to fix this with .css files, but I'm glad it's not an image rendering issue. (Whew) -- SH

The .png files themselves, if I open them on my local machine in Photoshop or Microsoft Photo Editor, have the transparent background. They just display in the browser window with the black background

-- KamArnold - 03 Feb 2006

Just installed the Dakar Release 04x00x00 myself, and noticed the following: The in-line images were mis-aligned using the default skin. To correct, comment out the following lines from pub/TWiki/PatternSkin/style.css

/* L149-151
img {
        vertical-align:text-bottom;
}
*/ 

-- SomeBodyElse - 04 Feb 2006

Is there any way to disable WikiWord rendering inside Latex formulas? When I use this formula

%\[
f_{norm} (A_i (BegPlPos_n ))
\]%

I get the rendered formula, but also some gibberish resulting from trying to render the WikiWord inside...

-- PeterLohmann - 06 Feb 2006

Thanks for the catch.

The WikiWord hyperlink is appearing the the alt tag of the image. To disable, add the following line to LatexModePlugin.pm (L498 or so, in v2.21)

        #remove any quotes in the string, so the alt tag doesn't break
        $escaped =~ s/\"/"/gso;
        $escaped =~ s/\n/ /gso;
        # NEW LINE:
        $escaped =~ s!(\u\w\l\w+\u\w)!<nop>$1!g;

Update: Corrected. The above now works in both Cairo and Dakar.

-- ScottHoge - 06 Feb 2006

Thanks for the quick fix, Scott!

A small bug remains though: In the above formula BegPlPos is recognized as WikiWord, so that my latex output shows a small (unwanted) '?' inside the formula.

• Bizarre. I'm unable to reproduce this, on either my Cairo or Dakar installs. More details maybe? (os, server, and browser versions?) -- SH

Another thing I noticed is that the %BEGINFIGURE...% functionality is not working... It seems that Latex is not able to find the endfigure tag (although it is defined correctly in the topic text).

! LaTeX Error: \begin{figure} on input line 158 ended by \end{document}.

• I suspect here that something else is mis-rendering, and confusing the latex processor. If you turn the DEBUG mode on, the intermediate latex file will remain in a tmp folder after processing. That file should provide more clues as to why the figure environment failure is occuring. -- SH

-- PeterLohmann - 09 Feb 2006

Strange. What may be wrong with my setup if I get a growing (with every refresh of the topic) list of Twiki error messages at the bottom of my local LatexModePlugin topic?

Twiki LatexModePlugin error messages:
   Error! multiple equation labels 'eqn:one' defined. (Eqns. 1 and 1)
   Error! multiple equation labels 'eqn:one' defined. (Eqns. 1 and 1)
   Error! multiple equation labels 'eqn:one' defined. (Eqns. 1 and 1)
   Error! multiple equation labels 'eqn:one' defined. (Eqns. 1 and 1)
   Error! multiple equation labels 'eqn:one' defined. (Eqns. 1 and 1)
   Error! multiple equation labels 'eqn:one' defined. (Eqns. 1 and 1)
   Error! multiple equation labels 'eqn:one' defined. (Eqns. 1 and 1)

• I'm concerned that this indicates a bug... what is the setup here? -- SH

-- FranzJosefSilli - 14 Feb 2006

Found the solution, this appears if you set warnings equal errors in configure.

-- FranzJosefSilli - 14 Feb 2006

I changed line 718 of

lib/TWiki/Plugins/LatexModePlugin.pm

from

$cmd .= "-shave ".round(2*$ptsz)."x".round(2*$ptsz)." "

to

$cmd .= "-shave ".round(1*$ptsz)."x".round(2*$ptsz)." "

because the right-hand side of the images was getting cut off. Before %$P$% rendered , now it renders .

Is that the right fix?

Is the problem unique to my installation? If so, I'll supply details.

• The in-line-rendering code apparently needs a bit of polishing :-). Your fix is certainly reasonable, but I would like to find something a bit cleaner overall. -- SH

-- ShaughanLavine - 14 Feb 2006

The rendering process on my (underpowered) machine takes ages, one call to gs more than a minute, so I end up with 500 Internal Server Error. Are there some options to speed up the process, exp. gs, maybe leave some parameter?

Maybe, you could use pdflatex instead and directly converting the pdf to png. This should need (in theory) less time. Sidenote: I heared, the pdflatex engine is somewhat better in subpixel positioning, too, but I think (not sure), this engine is also used in newer latex versions...

There is also preview-latex, initially written as helper tool for (x)emacs and now part of auctex, which converts dvi directly to png and it claims to be very fast.

-- TobiasRoeser - 20 Feb 2006

Tobias, Thanks for the tip. I do like preview-latex, but always thought it used dvips and gs in the background. However, from the manual,

dvipng is much faster than the combination of Dvips and Ghostscript.

I'll look in to this, promptly

-- ScottHoge - 20 Feb 2006

V 2.4 released today. This release corrects a number of bugs:

• The in-line rendering "enhancement" of v2.3 has shown to be problematic (See 1 and 2 above). The enhancements are now optional.
• The WikiWord rendering in alt field of image tags 3 is now fixed.
• .css conflict 4 resolved
• Through the addition of a donotrenderlist, Administrators now have the ability to disable commands of their choosing. This was provided to prevent the use of \input and \include in the Latex rendering on publicly accessible sites. If folks find other commands that can show more than intended, please share them here.

Publicly accessible sites are encouraged to upgrade.

-- ScottHoge - 21 Feb 2006

Using a greater-than sign in math louses up own-line display in version 2.4:
in %\[ > /]% display
on its own line renders with the word display on the same line as the >, with that line centered, like this:
in

> display instead of like this:
in > display
which is what should happen.

There is an easy workaround: use \textgreater instead of the symbol.

• I haven't seen this myself. In the example above, there is a syntax error. Using \]% in place of /]%, e.g. %\[ > \]%, should render without problems. And thanks for pointing out \textgreater, that command will come in handy with the WYSIWYG plugin. -- SH

-- ShaughanLavine - 25 Feb 2006

I may have overlooked it, but if you have a multi-page latex doc, is there a way to display it?

• Interesting. What exactly did you have in mind? One could attach a PDF version of the latex doc. Alternatively, one could show a thumbnail image (of the first page?) or a readable size image (of all pages?). Such things would be pretty easy with ghostscript, but it may take some plugin tweaking (or creating). One of the requests among my own group is to have an easy way to convert existing latex files into TWiki. I haven't yet decided on the best/easiest way to do this. -- SH

-- DavidZage - 25 Feb 2006

My group has many older, longer latex documents from research and collaboration. It would be nice to have the ability to quickly preview and make minor changes by just having the latex in the wiki. The ability to actually convert the latex into TWiki would also be very interesting.

-- DavidZage - 26 Feb 2006

I've started a discussion page over on Codev, TWiki:Codev.IncludeExistingLatexDocsInTWiki, to discuss and strategize on how needs such as the one expressed by DavidZage above can be met.

-- ScottHoge - 27 Feb 2006

For a comparison of this plugin with other math related plugins, please see ComparisonMathLatexPlugins.

-- AmandaSmith - 01 Mar 2006

I am trying to install LatexModePlugin on a Windows 2000 system but when I use it, I get no formulas but the following message at the end of the page:

"Latex rendering error!! DVI file was not created."

. The png pictures refered to in the pages do not exist in the directory where they should be "D:\Twiki\pub\Sandbox\WebHome".

The error message not only occurs in the preview page but also on the normal page (this development page states that it should only occur in the preview page).

As far as I can check, I installed and checked everything needed (Digest::MD5, Image::Info perl, MikTex, GhostScript, ImageMagick's convert) and added the following lines to "TWiki.cfg":

  $TWiki::cfg{Plugins}{LatexModePlugin}{latex} = 'C:/texmf/miktex/bin/latex';
  $TWiki::cfg{Plugins}{LatexModePlugin}{dvips} = 'C:/texmf/miktex/bin/dvips';
  $TWiki::cfg{Plugins}{LatexModePlugin}{convert} = 'C:/Program Files/ImageMagick-6.2.6-Q16/convert';

I also restarted windows.

Somewhere above it suggest that there is a "latex.log" file with more error information (on Unix). Is there something like that on a Windows installation?
Wait, I found something in the 'Log Files' section of the configure page, they are supposed to appear in the "D:\Twiki\data" directory. I looked in LatexModePlugin.pm and turned on the debugging by adding $debug=1; (I didn't find a flag in configure). The debug information that I get looks fine to me. Also the tempory tex file that is generated in C:\temp looks fine to me.

Looked a bit further by tweaking LatexModePlugin.pm
The problem is the following line, which seems to be designed for use with Linux only:

system("$PATHTOLATEX $LATEXFILENAME >> $LATEXLOG 2>&1");

I also tried:

system("$PATHTOLATEX $LATEXWDIR\\$LATEXFILENAME >> $LATEXLOG);

I could run this line from a command prompt and get a proper result (twiki_math.dvi output file) but I couldn't get it to produce any output files from the LatexModePlugin.pm yet.

One extra clue: the apache error log states:

  view: Can't spawn "cmd.exe": No such file or directory at D:/Twiki/lib/TWiki/Plugins/LatexModePlugin.pm line 729 ...

Line 729 is the 'system' call given above.

If I hard code the path to cmd.exe in LatexModePlugin.pm:

  $ENV{PATH} = "C:/WINNT/system32";

Then the spawn error disappears but I get the following error in the apache log:

  'C:/Program' is not recognized as an internal or external command

I suppose it should be 'Program Files'. I went on to look where a program in 'Program Files' was called and it appears to be ImageMagick's convert. I changed the path for it in the TWiki.cfg from the above mentioned line into:

  $TWiki::cfg{Plugins}{LatexModePlugin}{convert} = 'C:/Progra~1/ImageMagick-6.2.6-Q16/convert';

And now I've got formulas!

Sorry to bother you with this. I will leave it in here. Maybe it is of help for others.

-- TeunVanDenDool - 05 Mar 2006

I still found an odd bug (I think it is). If I try to visit the LatexModePlugin page (http://twiki-vm/twiki/bin/view/TWiki/LatexModePlugin), I get the following error:

Access denied
Access check on TWiki.LatexModePlugin failed.
Action "CHANGE": access not allowed on web. 

I have also done a LatexModePlugin installation on TwikiVMware and it gives the same error. Has anybody any idea where this comes from?

-- TeunVanDenDool - 08 Mar 2006

I believe this is caused by a permissions error for the pub/TWiki/LatexModePlugin directory in TWiki 4.0.x. i.e. TWikiGuest can view the page, but can't upload images. I haven't given much thought on how to correct it in the release. Changing permissions on the topic (or twiki web) long enough to generate the images should be enough to solve the problem.

-- ScottHoge - 08 Mar 2006

I wasn't able to find the way to change the permissions. But I logged in as real user (on a Debian installation) and then I can display the page. On my Windows system I don't know how to log in as a user (or add a user).

-- TeunVanDenDool - 10 Mar 2006

I've installed v2.4 but am still having trouble related to 1. Turning the inline tweak on, I get some statements that look fine, but others that have underlines.

• Using the tweakinline variable with a statement rendered incorrectly:
  
• Using the tweakinline variable with a statement rendered correctly:
  

Then I play with the statements as one would assume given in 1, but to no avail; any suggestions?

-- IanTegebo - 9 Mar 2006

LatexModePlugin still uses the endRenderingHandler (which will be deprecated (some day)), does it?

-- FranzJosefSilli - 11 Mar 2006

Ian, modifying the Perl script to increase the "shave" setting should reduce the underline problem... but, there really must be a better way to do this. I just haven't had time to look at it.

Franz, Yes, but mostly no. Currently, the endRenderingHandler is an empty hook to postRenderingHandler. It is needed in Cairo installs. Dakar users can comment the subrountine out.

-- ScottHoge - 11 Mar 2006

There was a typo in 4, but that has nothing to do with the issue. You can see it, for example, at https://kszk.sch.bme.hu/twiki/bin/view/TWiki/LatexModePlugin, which I just found by Googling: In the "Examples" section of that page, the %\[ \sigma_1 > \sigma_2 > \cdots > \sigma_n \geq 0 \]% is rendered on the same line as the following text ("along the main diagonal…") instead of centered in display, as it should be. That is a result of the bug about rendering >. You can also see it on my site, along with some additional information about the bug.

-- ShaughanLavine - 11 Mar 2006

Scott--

I should add that I love the plugin and rely on it extensively, which is why the bugs are worth noting. Thanks for the good work.

A feature request: Is there some way to force an entire page to re-render? If not, there should be. Perhaps a binary variable that can be set, like

• Set RENDERALL = 1

When I'm having trouble getting something to display as I want it to, I've often been reduced to adding spaces or the like to get the hash values to change.

-- ShaughanLavine - 11 Mar 2006

Hi Shaughan,

I've attached a screenshot of the page at your site. Could this bug be browser specific? Both examples appear to render correctly for me in firefox.

Updated: I can now see at least in part what is going on. This, (the plugin generated output):

<div align="center"><img src="/twiki/pub/TWiki/LatexModePlugin/latex303abc4184b439b709dcefbc28d2ac3c.png" width="161" height="14" alt="\[ \<nop>sigma_1 > \<nop>sigma_2 > \<nop>cdots > \<nop>sigma_n \<nop>geq 0 \]" /></div>

is being converted to this:

<div align="center"><img src="/twiki/pub/TWiki/LatexModePlugin/latex303abc4184b439b709dcefbc28d2ac3c.png" width="161" height="14" alt="\[ \sigma_1 > \sigma_2 &gt; \cdots &gt; \sigma_n \geq 0 \]" /&gt;></div>

somewhere farther along the twiki processing chain. Different browsers may, or may not, render the above lines identically. Firefox, appears to be immune from the difference. Nonetheless, I agree it should be fixed.

And yes, certainly, a renderall hook is a good idea. I would probably choose to pass it in as a url parameter than a topic setting, however.

(BTW. I liked your site!)

-- ScottHoge - 12 Mar 2006

In the new release today: a bug fix, a new feature, and support for dvipng.

-- ScottHoge - 14 Mar 2006

Great, the LatexModePlugin page on my machine gets now rendered with hardly perceivable speed slow down, compared to the same page with disabled LatexModePlugin.

This is fantastic, as the version using dvips + ghostscript takes ages and often resulted in a server timeout. Thanks for implementing the dvipng rendering. Lesser dependencies, faster rendering, ...good improvement.

-- TobiasRoeser - 14 Mar 2006

The new release is great, but the manifest lists data/TWiki/LatexIntro.txt, and it is missing from the zip. I still need to fiddle with the shave parameters to avoid cutting off the rhs of images.

-- ShaughanLavine - 19 Mar 2006

Version 2.5 produces an error message together with mailnotify on Cairo:

Can't call method "param" on an undefined value at /usr/share/perl5/TWiki/Plugins/LatexModePlugin.pm line 210.

Fix:

--- LatexModePlugin.pm~ 2006-03-14 20:29:57.000000000 +0100
+++ LatexModePlugin.pm  2006-04-25 22:42:31.518095672 +0200
@@ -207,9 +207,12 @@
     $rerender = &TWiki::Func::getPreferencesValue( "RERENDER" ) || 0;
+    if (defined($query)) {
         if ($query->param( 'latex' )) {
             $rerender = ($query->param( 'latex' ) eq 'rerender');
         }
+    }

     # Plugin correctly initialized

-- ChristopherHuhn - 25 Apr 2006

I love this plugin. I haven't been able to install dvipng on my Mac OS X machine, yet, so I'll have to come back when that's working.

For right now, I have a couple of suggestions, in the form of a patch:

1. I really think that the variable names like DENSITY, GAMMA, SCALE, and PREAMBLE are far too generic, so I'm using LATEXMODEDENSITY, etc.
2. I find that the default behavior for %$ chops too much off the left and right of inline eguations, so I pad with a space, see "pad against chopping"

--- ~/LatexModePlugin.pm 2006-03-14 11:29:57.000000000 -0800
+++ LatexModePlugin.pm  2006-04-26 14:55:23.000000000 -0700
@@ -175,26 +175,26 @@
     $pubUrlPath = # &TWiki::Func::getUrlHost() . 
         &TWiki::Func::getPubUrlPath() . "/$web/$topic";
     
     # Get preferences values
     $debug = &TWiki::Func::getPreferencesFlag( "LATEXMODEPLUGIN_DEBUG" );
     $default_density = 
-        &TWiki::Func::getPreferencesValue( "DENSITY" ) ||
+        &TWiki::Func::getPreferencesValue( "LATEXMODEDENSITY" ) ||
         &TWiki::Func::getPreferencesValue( "LATEXMODEPLUGIN_DENSITY" ) || 
         116;
     $default_gamma = 
-        &TWiki::Func::getPreferencesValue( "GAMMA" ) ||
+        &TWiki::Func::getPreferencesValue( "LATEXMODEGAMMA" ) ||
         &TWiki::Func::getPreferencesValue( "LATEXMODEPLUGIN_GAMMA" ) ||
         0.6;
     $default_scale = 
-        &TWiki::Func::getPreferencesValue( "SCALE" ) ||
+        &TWiki::Func::getPreferencesValue( "LATEXMODESCALE" ) ||
         &TWiki::Func::getPreferencesValue( "LATEXMODEPLUGIN_SCALE" ) ||
         1.0;
 
     $preamble = 
-        &TWiki::Func::getPreferencesValue( "PREAMBLE" ) ||
+        &TWiki::Func::getPreferencesValue( "LATEXMODEPREAMBLE" ) ||
         &TWiki::Func::getPreferencesValue( "LATEXMODEPLUGIN_PREAMBLE" ) ||
         '\usepackage{latexsym}'."\n";
 
     # initialize counters
     # Note, these can be over-written by topic declarations
     $eqn = &TWiki::Func::getPreferencesValue( "EQN" ) || 0;
@@ -228,13 +228,13 @@
     
     # handle floats first, in case of latex markup in captions.
     $_[0] =~ s!%BEGINFIGURE{(.*?)}%(.*?)%ENDFIGURE%!&handleFloat($2,$1,'fig')!giseo;
     $_[0] =~ s!%BEGINTABLE{(.*?)}%(.*?)%ENDTABLE%!&handleFloat($2,$1,'tbl')!giseo;
 
     ### handle the standard syntax next
-    $_[0] =~ s/%(\$.*?\$)%/&handleLatex($1,'inline="1"')/gseo;
+    $_[0] =~ s/%(\$.*?\$)%/&handleLatex(" ".$1." ",'inline="1"')/gseo; # pad against chopping
     $_[0] =~ s/%(\\\[.*?\\\])%/&handleLatex($1,'inline="0"')/gseo;
     $_[0] =~ s/%MATHMODE{(.*?)}%/&handleLatex("\\[".$1."\\]",'inline="0"')/gseo;
     
     # pass everything between the latex BEGIN and END tags to the handler
     # 
     $_[0] =~ s!%BEGINLATEX{(.*?)}%(.*?)%ENDLATEX%!&handleLatex($2,$1)!giseo;

-- TroyGoodson - 26 Apr 2006

AmandaSmith made some changes to the Plugin topic and added LatexSymbols, LatexSymbols2, LatexSymbols3, LatexSymbols4 and LatexSymbols5. Please consider this for the next release.

-- PeterThoeny - 27 Apr 2006

Amanda and Troy, thanks for the suggestions. The DENSITY/GAMMA/etc change is significant, so I'll hold off on that until the next major release. The tweak-inline code is so very sensitive to different tex implementations, that I choose to not add in the %$ $% suggestion. (i.e. it added too much space on my linux server). I'll leave the choice of spliting the LatexSymbols page up to the admins. Today release fixes the bug noted on 25Apr2006.

-- ScottHoge - 19 May 2006

Hello,

How secure is the LatexModePlugin? I'm puzzled as to why texvc and WikiTex over there with MediaWiki restrict users to a subset of Latex / Tex commands or packages, whereas LatexModePlugin apparently doesn't. Our team works with Latex documents, and, hence, this plugin seems perfect. Could you give some insight into the security aspect of using Latex on a (T)Wiki? Thanks.

-- PeterSaentis - 10 Jun 2006

Hi Peter,

Thanks for the inquiry. My understanding is that texvc approached the security issue from a white-list perspective, meaning that only approved commands can be used in LaTeX mode. In reading back through the archived discussions, it appears this decision was driven as much by the desire to keep the mark-up language simple as for security. I (and many others, it appears) felt this was too restrictive, as it required one to reimplement tex.

Recently, the WikiTex developers have abandoned the white-list/black-list approach in favor of using a combination of "ulimit, quotas, chroot, and a properly configured texmf.cnf;" E.g., from the wikitex README:

Edit `texmf.cnf', modifying the following variables:
    shell_escape = f
    openout_any = p
    openin_any = p  % note this won't work on Windows

This is certainly an encouraged approach to take with TWiki and the LatexModePlugin as well.

To answer your question, the security in LatexModePlugin is moderate. Because of this, all editing on my own wiki is restricted to trusted users, i.e. members or colleagues of our lab. Via restricted rendering capabilities, the MathModePlugin is more secure and better suited (at this point) to a public wiki. To correct the 'image rotation bug' it would take very little work to port the dvipng rendering code from the LatexModePlugin to the MathModePlugin.

A few steps can be taken at installation to make the LatexModePlugin more secure, at the expense of reduced functionality:

• expand the donotrender list to include { def, newcommand }, and likely { newenvironment, newfont, newtheorem, newsavebox } as well
• disable the %BEGINLATEXPREAMBLE% macro and PREAMBLE settings (by commenting out L196,L197,L244 of LatexModePlugin.pm (v2.51))

more to follow soon

-- ScottHoge - 12 Jun 2006

Limiting CPU process time in apache can be achieved via this declaration: http://httpd.apache.org/docs/1.3/mod/core.html#rlimit as,

There are just too many ways to make TeX go into infinite loops to prevent them all while maintaining good functionality. [source]

-- ScottHoge - 12 Jun 2006

Security Follow-up

The WikiTex and MoinMoin LaTeX extension developers have done a thorough job in setting up as secure latex environment within their respective wikis. Here are a few links to consider:

• http://meta.wikimedia.org/wiki/Texvc
• http://www.mail-archive.com/tetex@dbs.uni-hannover.de/msg00459.html
• http://johannes.sipsolutions.net/Projects/new-moinmoin-latex/security-considerations

Looking over the recent changes in WikiTex, the latex rendering needs to robust to the following constructs:

• \def\a{\a}\a
• \input{/etc/passwd}
• \immediate\write18{ls}

• \immediate\openout0=../test\relax
  \write0{\noexpand\bf byebye}
  \closeout0
  

Setting the texmf.cnf file as above, using the donotrender list in the plugin code, and limiting the CPU time available on the server will cover these four items. This will give security almost as good as the latest WikiTex.

One change I intend to incorporate in a future release is the use of the Dakar Sandbox. CGI inputs are scrubbed currently, so this is a less pressing priority. The change will bring consistency to the plugin, as well as piece-of-mind.

-- ScottHoge - 12 Jun 2006

TODO: After helping a student get started on a topic today, I came to the conclusion that the handling of latex errors could be dramatically improved. Currently, if there is an error, the error message appears at the bottom of the preview screen. Mapping this message back to the problematic markup can be difficult though, since markup in the latex file that is processed may be in a different order than on the wiki page. A better presentation would be to place the "Error" message where the image should normally appear, and render all valid markup.

I'm not sure when I'll have time to get to this, so if someone wants to take it on, let me know.

-- ScottHoge - 27 Jun 2006

Minor Bug: LatexModePlugin fails to create the webname directory in the ...twiki/pub/ directory if it not already present (probably because it is a newly created web). It can create the topicname folder if the webname folder is already present, but assumes the webname folder is always present. This bug would likely affect people who are trying out TWiki software and might convince them that this wonderful plugin simply doesn't work.

-- BenWatts - 15 Jul 2006

Thanks for the catch! I'll look in to it and post a correction soon

-- ScottHoge - 15 Jul 2006

New release today, to sweep clean a number of outstanding items.

Based on CC's comments on the apprasial form, this (v2.6) will likely be the last release that is compatible with Cairo. I haven't found an easy way in Cairo to pass values between functions/plugins without using globals, and this conflicts with mod_perl. Dakar provides getContext which takes care of this conflict.

Enjoy. (or wait a bit for the mod_perl compatible version)

-- ScottHoge - 05 Aug 2006

I believe I have found a bug in the new v2.6 of the plugin. After I installed the update, pages in my wiki broke and downgrading to v2.51 made them work again. It appears that if you do a

%INCLUDE{"MyLatexPage"}%

on any page where the included pages has Latex markups, the page that does the include fails to render even though the original page renders correctly when viewed. The error that I get on the included page in the browser is

Can't call method "sysCommand" on an undefined value

. In the twiki log file I see:

| 07 Aug 2006 - 16:01 | Can't call method "sysCommand" on an undefined value at
/var/lib/twiki/lib/TWiki/Plugins/LatexModePlugin.pm line 801. 

-- RickMach - 07 Aug 2006

Thanks for the feedback. I couldn't repeat the exact error on TWiki4, but the rendering of included topics was definitely broken.

I uploaded a new version which should fix the problem. Also, added a background color option (after Micha's latest MathModePlugin), to improve rendering such as the following:

-- ScottHoge - 08 Aug 2006

I found a "bug" in 2.51. I believe it persists in 2.61, but I have not tested well: On RedHat systems, the default is for root to have mv, rm, and cp aliased to mv -i, etc., and that prevents ?latex=rerender from working properly. (Of course, this is really a bug in RedHat best cured by unalias {mv,rm,cp}, but still, it took me a while to figure out what was wrong, and so ….)

-- ShaughanLavine - 11 Sep 2006

I get a Latex rendering error!! DVI file was not created. (apache runs as user apache and all directories under /var/www/html/twiki etc are chowned to apache:apache and pub and data are writable (777) - it is puzzling because I think I did it the same way on another linux machine and it is working fine - but I do not remember what I had to set/unset/chmod/chown (!) ... Wonder what the solution is? I am on 4.0.4

-- KrishnanChittur - 14 Sep 2006

Krishnan,

It is likely a path error, either on the side of the creation tools or the temporary directory. My recommendation is to turn the debug mode on, and then look for the twiki_math.tex file and the associated log file(s). Depending on what is (or is not) created, that should help track down the issue.

Shaughan, thanks for pointing this out. I'm not sure is can be addressed in the plugin, however. The plugin uses perl's unlink command to delete files, which gets mapped to system commands somewhere within perl. So, useful to know, but I think tihs is truly a system-level issue that is transparent to the plugin.

-- ScottHoge - 15 Sep 2006