Introducing the equation rendering component and the equation macro

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Introducing the equation rendering component and the equation macro

Sergiu Dumitriu-2
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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Introducing the equation rendering component and the equation macro

Jean Couteau
Hello Sergiu
>
> 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.
>  
Nice job, I did not try it as I have no concrete use now, but anyway,
that's a really nice feature as equations are always hard to write for
nice display.

> 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?
>  
I think, at least png and jpg should be kept. Png as default, and jpg as
optional (there are still a lot of jpg fans  i guess), for the GIF
format, i don't think it is necessary.
> 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
>  



> 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?
>  
I don't think you can find 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.
>  

Keep up the good work...

And thanks for this nice feature.

Jean

--
----
Jean Couteau
Code Lutin - http://www.codelutin.com
44 Bd des Pas Enchantés - 44230 St-Sébastien/Loire
Tél : 02 40 50 29 28 - Fax : 09 59 92 29 28

_______________________________________________
users mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Introducing the equation rendering component and the equation macro

Thomas Mortagne
Administrator
In reply to this post by Sergiu Dumitriu-2
On Mon, Aug 10, 2009 at 16:14, Sergiu Dumitriu<[hidden email]> 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

I don't like this name either "rendering" is too much linked to the
rendering module now and this could be used by anyone, not only the
equation macro.

It's also true that xwiki-equation is not clear enough but you could
maybe find something else.

> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/users
>



--
Thomas Mortagne
_______________________________________________
users mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Introducing the equation rendering component and the equation macro

Guillaume Lerouge
Hi,

On Mon, Aug 10, 2009 at 4:33 PM, Thomas Mortagne
<[hidden email]>wrote:

> On Mon, Aug 10, 2009 at 16:14, Sergiu Dumitriu<[hidden email]> 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?
>

I think keeping PNG as the default format is fine too, most browsers accept
it without complaint.


>
> >
> > 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
>
> I don't like this name either "rendering" is too much linked to the
> rendering module now and this could be used by anyone, not only the
> equation macro.
>
> It's also true that xwiki-equation is not clear enough but you could
> maybe find something else.


xwiki-equation-displayer maybe ?


>
>
> > 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?
> >
> >
>

I think "equation" is fine.


>
> >
> > 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.
>

Good work, thanks Guillaume & Sergiu !

Guillaume


>
> > --
> > Sergiu Dumitriu
> > http://purl.org/net/sergiu/
> > _______________________________________________
> > users mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/users
> >
>
>
>
> --
> Thomas Mortagne
> _______________________________________________
> users mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/users
>



--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
users mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Introducing the equation rendering component and the equation macro

Asiri Rathnayake
Hi,

On Mon, Aug 10, 2009 at 8:08 PM, Guillaume Lerouge <[hidden email]>wrote:

> Hi,
>
> On Mon, Aug 10, 2009 at 4:33 PM, Thomas Mortagne
> <[hidden email]>wrote:
>
> > On Mon, Aug 10, 2009 at 16:14, Sergiu Dumitriu<[hidden email]> 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?
> >
>
> I think keeping PNG as the default format is fine too, most browsers accept
> it without complaint.
>
>
> >
> > >
> > > 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
> >
> > I don't like this name either "rendering" is too much linked to the
> > rendering module now and this could be used by anyone, not only the
> > equation macro.
> >
> > It's also true that xwiki-equation is not clear enough but you could
> > maybe find something else.
>
>
> xwiki-equation-displayer maybe ?
>

Few more suggestions: xwiki-equation-plotter, xwiki-formula-plotter,
xwiki-formula

- Asiri
_______________________________________________
users mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Introducing the equation rendering component and the equation macro

Asiri Rathnayake
On Mon, Aug 10, 2009 at 9:44 PM, Asiri Rathnayake <
[hidden email]> wrote:

> Hi,
>
> On Mon, Aug 10, 2009 at 8:08 PM, Guillaume Lerouge <[hidden email]>wrote:
>
>> Hi,
>>
>> On Mon, Aug 10, 2009 at 4:33 PM, Thomas Mortagne
>> <[hidden email]>wrote:
>>
>> > On Mon, Aug 10, 2009 at 16:14, Sergiu Dumitriu<[hidden email]> 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?
>> >
>>
>> I think keeping PNG as the default format is fine too, most browsers
>> accept
>> it without complaint.
>>
>>
>> >
>> > >
>> > > 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
>> >
>> > I don't like this name either "rendering" is too much linked to the
>> > rendering module now and this could be used by anyone, not only the
>> > equation macro.
>> >
>> > It's also true that xwiki-equation is not clear enough but you could
>> > maybe find something else.
>>
>>
>> xwiki-equation-displayer maybe ?
>>
>
> Few more suggestions: xwiki-equation-plotter, xwiki-formula-plotter,
> xwiki-formula
>

Another idea:

xwiki-plotting
|-xwiki-plotting-equation
|-xwiki-plotting-graph

- Asiri
_______________________________________________
users mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Introducing the equation rendering component and the equation macro

Asiri Rathnayake
On Mon, Aug 10, 2009 at 9:48 PM, Asiri Rathnayake <
[hidden email]> wrote:

>
>
> On Mon, Aug 10, 2009 at 9:44 PM, Asiri Rathnayake <
> [hidden email]> wrote:
>
>> Hi,
>>
>> On Mon, Aug 10, 2009 at 8:08 PM, Guillaume Lerouge <[hidden email]>wrote:
>>
>>> Hi,
>>>
>>> On Mon, Aug 10, 2009 at 4:33 PM, Thomas Mortagne
>>> <[hidden email]>wrote:
>>>
>>> > On Mon, Aug 10, 2009 at 16:14, Sergiu Dumitriu<[hidden email]>
>>> 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?
>>> >
>>>
>>> I think keeping PNG as the default format is fine too, most browsers
>>> accept
>>> it without complaint.
>>>
>>>
>>> >
>>> > >
>>> > > 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
>>> >
>>> > I don't like this name either "rendering" is too much linked to the
>>> > rendering module now and this could be used by anyone, not only the
>>> > equation macro.
>>> >
>>> > It's also true that xwiki-equation is not clear enough but you could
>>> > maybe find something else.
>>>
>>>
>>> xwiki-equation-displayer maybe ?
>>>
>>
>> Few more suggestions: xwiki-equation-plotter, xwiki-formula-plotter,
>> xwiki-formula
>>
>
> Another idea:
>
> xwiki-plotting
> |-xwiki-plotting-equation
> |-xwiki-plotting-graph
>

Sorry, I meant xwiki-plotting-chart not "graph". Anyway, I think both are
same :-?


>
> - Asiri
>
>
_______________________________________________
users mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Introducing the equation rendering component and the equation macro

vmassol
Administrator
In reply to this post by Sergiu Dumitriu-2
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/E​quation).
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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/users

_______________________________________________
users mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Introducing the equation rendering component and the equation macro

Elena-Oana Tabaranu
In reply to this post by Sergiu Dumitriu-2
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?
>  
I would like the PNG output as default, but also keep the GIF and JPEG
since there are some problems with PNG images on "ancient" IE6.

Oana

> 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.
>  

_______________________________________________
users mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [xwiki-devs] Introducing the equation rendering component and the equation macro

Sergiu Dumitriu-2
In reply to this post by vmassol
Paul Libbrecht wrote:
> I would suggest xwiki-formula-rendering
>
> All equations are formulæ, all formulæ are not equations!
> Sergiu, is there a URL I can see this in more details?
> Do you tackle baseline? (with javascript probably).

No, it is in the Future Work list.

>
>
> Le 10-août-09 à 18:27, Vincent Massol a écrit :
>
>> 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/E​quation).
>> I'd prefer formula which is more generic.


--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
users mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Introducing the equation rendering component and the equation macro

Sergiu Dumitriu-2
In reply to this post by Sergiu Dumitriu-2
Answering the questions:

Sergiu Dumitriu wrote:
> Q: Should I leave just PNG as the output format?

It seems that keeping JPG and GIF is still needed. Now, I'm thinking
that my initial approach (making this a per image option) is not good,
and instead it should be a per user/global option. It is more likely
that one user would want to see all images in the .gif format than an
author wanting to create an image in the .gif format for everybody else.

> Q: Is the default DPI setting OK?

Nobody commented on this, so I'm going to assume it's OK.

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

This question still needs some answers.

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

Point taken: formula is better than equation. Actually, initially it was
named "formula", but I didn't like it that much. Anyway, the community
has spoken.

Point not taken: rendering is the right name IMO. Before xwiki-rendering
as a syntax converter, rendering has a widely accepted sense as
generating raster graphics. From Wikipedia: "Rendering is the process of
generating an image from a model, by means of computer programs". This
is what the module does, and the fact that we have another thing called
"rendering" doesn't mean that we must invent new names for something
standard.

Plotting is different, it involves vectorial graphics, and I tend to
associate it with Logo and its turtle. Displayer is different, it means
actually presenting the image to the user. LCDs display, papers display,
but this module is just creating raster images in memory.

> 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

Add: making it work with PDFs and other exports.

--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
users mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/users