[xwiki-devs] Introducing the equation rendering component and the equation macro
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/
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 [email protected] http://lists.xwiki.org/mailman/listinfo/users
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/Equation). I'd prefer formula which is more generic.
Thanks -Vincent
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/Equation). I'd prefer formula which is more generic.
-- Sergiu Dumitriu http://purl.org/net/sergiu/
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
[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... -- Sergiu Dumitriu http://purl.org/net/sergiu/
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/
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.
On Tue, Aug 11, 2009 at 16:10, Vincent Massol<[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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/
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
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
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/
+1 On Tue, Aug 11, 2009 at 17:06, Vincent Massol<[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (5)
-
[Ricardo Rodriguez] Your EPEC Network ICT Team -
Paul Libbrecht -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol