Hello Community,

I have committed today the first implementation of a new XWiki feature: 
rendering mathematical equations into images. It is available as a 
standalone component, and as a syntax 2.0 macro.

About the functionality.

Equations are written in the TeX/LaTeX syntax, which is pretty simple, 
and seems to be the syntax of choice for mathematical equations in other 
wikis, too. The macro can distinguish between inline and block equations 
and render them accordingly. The output can be either PNG (the default 
one), GIF or JPEG. While PNG is definitely the best, I kept the other 
two in case somebody really wants to use ancient browsers that only 
understand GIF.

Q: Should I leave just PNG as the output format?

Another feature is that the font size can be specified, in order to 
render larger or smaller equations. All the font size commands from 
LaTeX (from \tiny to \Huge) have an equivalent. I renamed them to a more 
easy to understand name (also because the configuration is case 
insensitive, so there's no difference between large and LARGE).

By default images are generated so that the font looks relatively OK 
with the default XWiki skin on a 72 or 96 DPI display. They might look 
disproportionate with a different DPI, or with a different default font 

Q: Is the default DPI setting OK?

Second, a few technical details:

The standalone component is located in 
platform/core/xwiki-equation-rendering. I don't know if the name is the 
best (Vincent complained). On one hand, this describes better what the 
component does: it renders equations. On the other hand, it might cause 
confusion with the xwiki-rendering system.

The component currently has three implementations:

- a native one, which relies on the latex system being present. It gives 
the best results, from a graphical point of view, but requires the 
presence of external programs, and involves a slight overhead for 
starting new processes and for working with the disk. Currently it might 
have some security problems, I'll have to see if opening input and 
output files from TeX is a problem, or how to disable this. Any help 
from someone who know more about TeX?

Q: Does anybody know of any security issues with running latex, dvips or 
convert? Especially with the \openin and \openout commands?

- one which uses MathTran as a remote service through HTTP requests. It 
gives results as good as the native one, enhanced with some metadata, 
and depending on the configuration of the server, it might have better 
performance than the native one. The disadvantage is that it relies 
heavily on a remote server. Note that MathTran is free software, and can 
be installed locally on the same or a neighboring server. Oh, another 
minor problem is that it uses a variant of the TeX syntax, not LaTeX.

- one which uses SnuggleTeX and JEuclid to transform LaTeX into MathML, 
and then render it into images. The results are not as eye-pleasing as 
those obtained from LaTeX, but it is a self-contained solution, with no 
external dependencies.

SnuggleTeX uses the liberal 3-clause BSD license, JEuclid uses the 
Apache v2 license, so both can be deployed. Together, they weight in at 
730k, so it's not a big impact. The other two implementations are not 
contaminated by the licenses of the underlying system, so there's no 
license conflict.

Q: Should either one be removed?

Q: Do you know of any other (better) alternative?

By default the native renderer is used, since it gives the best results 
and doesn't depend on an external service. SnuggleTeX is configured as a 
backup (safe) renderer which kicks in when the default one isn't working 
(missing tex subsystem, or communication error with the remote server).

Q: Is this setup OK as the default one? (native by default, snuggletex 
as fallback).

The generated images are stored in a cache (using the cache component), 
for improved performance. This new cache might increase the memory 
requirements, but fortunately it is easy to configure.

The rendering macro is located in 
and the macro can be used with


Q: Is the macro name appropriate? Do you know of a better one?

Future work:
- make sure that there are no security issues with the Native backend
- add support for MathML display for the clients that understand it
- improve the alignment of images (especially for the Native backend), 
as right now they are a bit raised above the text baseline

Many thanks to Guillaume Legris who provided the starting point for this 
Sergiu Dumitriu
users mailing list

Reply via email to