I haven't read the mail yet, I'm just reacting to the name.
Equations means there is an equal sign (see http://en.wikipedia.
org/wiki/Equation).
I'd prefer formula which is more generic.
Thanks
-Vincent
On Aug 10, 2009, at 4:14 PM, Sergiu Dumitriu wrote:
> 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
> size.
>
> 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
> platform/core/xwiki-rendering/xwiki-renderig-macros/xwiki-rendering-
> macro-equation,
> and the macro can be used with
>
> {{equation}}\sum_{i=0}^{\infty}{{/equation}}.
>
> 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
> component.
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu/
> _______________________________________________
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
_______________________________________________
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
