Introducing the equation rendering component and the equation macro

classic Classic list List threaded Threaded
14 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/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

vmassol
Administrator
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

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

Re: Introducing the equation rendering component and the equation macro

rrodrigueznt
In reply to this post by Sergiu Dumitriu-2
Hi, Sergiu, all,

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.

Please, does this work open a door to LaTeX as a supported syntax for
XWiki? Not only for equations/formulas but for whole documents? Thanks.

Best,

Ricardo

--
Ricardo Rodríguez
Your EPEC Network ICT Team



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

Re: Introducing the equation rendering component and the equation macro

Sergiu Dumitriu-2
[Ricardo Rodriguez] Your EPEC Network ICT Team wrote:

> Hi, Sergiu, all,
>
> 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.
>
> Please, does this work open a door to LaTeX as a supported syntax for
> XWiki? Not only for equations/formulas but for whole documents? Thanks.

This, no, but the new parsing/rendering engine does. I see there already
is a tex part in
http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/tex/

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

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

Paul Libbrecht
In reply to this post by vmassol
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).

paul


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


_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

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

Re: Introducing the equation rendering component and the equation macro

vmassol
Administrator

On Aug 11, 2009, at 3:14 PM, Sergiu Dumitriu wrote:

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

I'd agree to use rendering but *only* if:

* It's integrated inside the xwiki-rendering module
* It's implemented as a XWiki Parser and Renderer (and thus we  
introduce a syntax for it)

I think it could fit well in the xwiki-rendering module. We'll need to  
adjust a few things (since it would be the first renderer to generate  
binary data) but that's a good thing.

WDYT?

Thanks
-Vincent

> 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.
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Introducing the equation rendering component and the equation macro

Thomas Mortagne
Administrator
On Tue, Aug 11, 2009 at 16:10, Vincent Massol<[hidden email]> wrote:

>
> On Aug 11, 2009, at 3:14 PM, Sergiu Dumitriu wrote:
>
>> 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.
>
> I'd agree to use rendering but *only* if:
>
> * It's integrated inside the xwiki-rendering module
> * It's implemented as a XWiki Parser and Renderer (and thus we
> introduce a syntax for it)
>
> I think it could fit well in the xwiki-rendering module. We'll need to
> adjust a few things (since it would be the first renderer to generate
> binary data) but that's a good thing.

We have to make rendering support binary as input and output so if it
makes sense for the output part it's a very good occasion to force us
to finish the design for it.

>
> WDYT?
>
> Thanks
> -Vincent
>
>> 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.
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
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 vmassol
Vincent Massol wrote:

> On Aug 11, 2009, at 3:14 PM, Sergiu Dumitriu wrote:
>>> 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.
>
> I'd agree to use rendering but *only* if:
>
> * It's integrated inside the xwiki-rendering module
> * It's implemented as a XWiki Parser and Renderer (and thus we  
> introduce a syntax for it)
>
> I think it could fit well in the xwiki-rendering module. We'll need to  
> adjust a few things (since it would be the first renderer to generate  
> binary data) but that's a good thing.
>
> WDYT?

Well, it doesn't actually do parsing or rendering. The code is really
small, and it just forwards the text to a service, which returns the
binary blob.

But I don't understand why do you insist on this conflict between image
rendering and text rendering?

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

Re: Introducing the equation rendering component and the equation macro

vmassol
Administrator

On Aug 11, 2009, at 4:17 PM, Sergiu Dumitriu wrote:

> Vincent Massol wrote:
>> On Aug 11, 2009, at 3:14 PM, Sergiu Dumitriu wrote:
>>>> 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.
>>
>> I'd agree to use rendering but *only* if:
>>
>> * It's integrated inside the xwiki-rendering module
>> * It's implemented as a XWiki Parser and Renderer (and thus we
>> introduce a syntax for it)
>>
>> I think it could fit well in the xwiki-rendering module. We'll need  
>> to
>> adjust a few things (since it would be the first renderer to generate
>> binary data) but that's a good thing.
>>
>> WDYT?
>
> Well, it doesn't actually do parsing or rendering. The code is really
> small, and it just forwards the text to a service, which returns the
> binary blob.
>
> But I don't understand why do you insist on this conflict between  
> image
> rendering and text rendering?

I'd really prefer that we call it xwiki-formula meaning that it  
contains APIs for formula manipulation (even if right now the only API  
we offer is one that generates an image). Same as we have xwiki-chart  
for manipulating charts.

Rendering has a strong connotation in xwiki land. It means http://code.xwiki.org/xwiki/bin/view/Modules/RenderingModule

+ the name is pretty long and ungainly (it seems nicer to me to keep  
module names as short as possible)

After more thinking I don't think it fits as a Renderer since the main  
idea of a Parser/Renderer is that you parse with any parser and you're  
able to use any renderer. This wouldn't be the case here.

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

Re: Introducing the equation rendering component and the equation macro

vmassol
Administrator

On Aug 11, 2009, at 4:56 PM, Vincent Massol wrote:

>
> On Aug 11, 2009, at 4:17 PM, Sergiu Dumitriu wrote:
>
>> Vincent Massol wrote:
>>> On Aug 11, 2009, at 3:14 PM, Sergiu Dumitriu wrote:
>>>>> 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.
>>>
>>> I'd agree to use rendering but *only* if:
>>>
>>> * It's integrated inside the xwiki-rendering module
>>> * It's implemented as a XWiki Parser and Renderer (and thus we
>>> introduce a syntax for it)
>>>
>>> I think it could fit well in the xwiki-rendering module. We'll  
>>> need to
>>> adjust a few things (since it would be the first renderer to  
>>> generate
>>> binary data) but that's a good thing.
>>>
>>> WDYT?
>>
>> Well, it doesn't actually do parsing or rendering. The code is really
>> small, and it just forwards the text to a service, which returns the
>> binary blob.
>>
>> But I don't understand why do you insist on this conflict between  
>> image
>> rendering and text rendering?
>
> I'd really prefer that we call it xwiki-formula meaning that it  
> contains APIs for formula manipulation (even if right now the only  
> API we offer is one that generates an image). Same as we have xwiki-
> chart for manipulating charts.
>
> Rendering has a strong connotation in xwiki land. It means http://code.xwiki.org/xwiki/bin/view/Modules/RenderingModule
>
> + the name is pretty long and ungainly (it seems nicer to me to keep  
> module names as short as possible)
>
> After more thinking I don't think it fits as a Renderer since the  
> main idea of a Parser/Renderer is that you parse with any parser and  
> you're able to use any renderer. This wouldn't be the case here.

Should the formula macro be in the xwiki-formula module (as a sub  
module for ex)? Or should it be in the rendering module? I think as we  
progress through componentization it should be in xwiki-formula so  
that we have self isolated modules that can  be used as is. This would  
remove deps between the rendering module and xwiki-formula for ex. So  
as soon as a business domain materializes, everything related to that  
domain should find its way inside the module for that domain IMO

ok I give in :)

so I would see:

xwiki-formula/
   L– xwiki-formula-renderer
   |_ xwiki-formula-macro

and

xwiki-chart/
   |_ xwiki-chart-renderer
   |_ xwiki-chart-macro

wdyt?

Thanks
-Vincent

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

Re: Introducing the equation rendering component and the equation macro

Sergiu Dumitriu-2
Vincent Massol wrote:

> On Aug 11, 2009, at 4:56 PM, Vincent Massol wrote:
>
>> On Aug 11, 2009, at 4:17 PM, Sergiu Dumitriu wrote:
>>
>>> Vincent Massol wrote:
>>>> On Aug 11, 2009, at 3:14 PM, Sergiu Dumitriu wrote:
>>>>>> 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.
>>>> I'd agree to use rendering but *only* if:
>>>>
>>>> * It's integrated inside the xwiki-rendering module
>>>> * It's implemented as a XWiki Parser and Renderer (and thus we
>>>> introduce a syntax for it)
>>>>
>>>> I think it could fit well in the xwiki-rendering module. We'll  
>>>> need to
>>>> adjust a few things (since it would be the first renderer to  
>>>> generate
>>>> binary data) but that's a good thing.
>>>>
>>>> WDYT?
>>> Well, it doesn't actually do parsing or rendering. The code is really
>>> small, and it just forwards the text to a service, which returns the
>>> binary blob.
>>>
>>> But I don't understand why do you insist on this conflict between  
>>> image
>>> rendering and text rendering?
>> I'd really prefer that we call it xwiki-formula meaning that it  
>> contains APIs for formula manipulation (even if right now the only  
>> API we offer is one that generates an image). Same as we have xwiki-
>> chart for manipulating charts.
>>
>> Rendering has a strong connotation in xwiki land. It means http://code.xwiki.org/xwiki/bin/view/Modules/RenderingModule
>>
>> + the name is pretty long and ungainly (it seems nicer to me to keep  
>> module names as short as possible)
>>
>> After more thinking I don't think it fits as a Renderer since the  
>> main idea of a Parser/Renderer is that you parse with any parser and  
>> you're able to use any renderer. This wouldn't be the case here.
>
> Should the formula macro be in the xwiki-formula module (as a sub  
> module for ex)? Or should it be in the rendering module? I think as we  
> progress through componentization it should be in xwiki-formula so  
> that we have self isolated modules that can  be used as is. This would  
> remove deps between the rendering module and xwiki-formula for ex. So  
> as soon as a business domain materializes, everything related to that  
> domain should find its way inside the module for that domain IMO
>
> ok I give in :)
>
> so I would see:
>
> xwiki-formula/
>    L– xwiki-formula-renderer
>    |_ xwiki-formula-macro
>
> and
>
> xwiki-chart/
>    |_ xwiki-chart-renderer
>    |_ xwiki-chart-macro
>
> wdyt?

+1

I'll move both of them now (formula and chart).

--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
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 vmassol
+1

On Tue, Aug 11, 2009 at 17:06, Vincent Massol<[hidden email]> wrote:

>
> On Aug 11, 2009, at 4:56 PM, Vincent Massol wrote:
>
>>
>> On Aug 11, 2009, at 4:17 PM, Sergiu Dumitriu wrote:
>>
>>> Vincent Massol wrote:
>>>> On Aug 11, 2009, at 3:14 PM, Sergiu Dumitriu wrote:
>>>>>> 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.
>>>>
>>>> I'd agree to use rendering but *only* if:
>>>>
>>>> * It's integrated inside the xwiki-rendering module
>>>> * It's implemented as a XWiki Parser and Renderer (and thus we
>>>> introduce a syntax for it)
>>>>
>>>> I think it could fit well in the xwiki-rendering module. We'll
>>>> need to
>>>> adjust a few things (since it would be the first renderer to
>>>> generate
>>>> binary data) but that's a good thing.
>>>>
>>>> WDYT?
>>>
>>> Well, it doesn't actually do parsing or rendering. The code is really
>>> small, and it just forwards the text to a service, which returns the
>>> binary blob.
>>>
>>> But I don't understand why do you insist on this conflict between
>>> image
>>> rendering and text rendering?
>>
>> I'd really prefer that we call it xwiki-formula meaning that it
>> contains APIs for formula manipulation (even if right now the only
>> API we offer is one that generates an image). Same as we have xwiki-
>> chart for manipulating charts.
>>
>> Rendering has a strong connotation in xwiki land. It means http://code.xwiki.org/xwiki/bin/view/Modules/RenderingModule
>>
>> + the name is pretty long and ungainly (it seems nicer to me to keep
>> module names as short as possible)
>>
>> After more thinking I don't think it fits as a Renderer since the
>> main idea of a Parser/Renderer is that you parse with any parser and
>> you're able to use any renderer. This wouldn't be the case here.
>
> Should the formula macro be in the xwiki-formula module (as a sub
> module for ex)? Or should it be in the rendering module? I think as we
> progress through componentization it should be in xwiki-formula so
> that we have self isolated modules that can  be used as is. This would
> remove deps between the rendering module and xwiki-formula for ex. So
> as soon as a business domain materializes, everything related to that
> domain should find its way inside the module for that domain IMO
>
> ok I give in :)
>
> so I would see:
>
> xwiki-formula/
>   L– xwiki-formula-renderer
>   |_ xwiki-formula-macro
>
> and
>
> xwiki-chart/
>   |_ xwiki-chart-renderer
>   |_ xwiki-chart-macro
>
> wdyt?
>
> Thanks
> -Vincent
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs