[xwiki-users] Latex html in editor for math formulas?
Hi folks, Will there be an additional button in the editor, to implement formulas? Or is there? Or how can I use formulas, maybe you know a good latex html live editor. Since xwiki is more and more used by universities and labs....it would be nice to have something, if there already isnt? Thanx, alan This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.
[email protected] wrote:
Hi folks,
Will there be an additional button in the editor, to implement formulas? Or is there?
Hi, You must be aware of this... http://i2geo.net/bin/Sandbox/Formulae There is at least a thread in xwiki-devs dealing with this issue. Look for MathTran there. http://www.nabble.com/forum/Search.jtp?forum=2564&local=y&query=MathTran Hope this helps, Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team
Oh thanks ricardo - that was quick I think the MathTran should be good for now....until maybe something in-editor is developed Do you have experience with MathTran and linking it to the page? Does it work good and project all LaTex formulae? That would be good to know, before i go out there and tell everybody i have a solution :-). Alan ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of [Ricardo Rodriguez] Your EPEC Network ICT Team Sent: Wednesday, 20 February 2008 09:57 To: XWiki Users Subject: Re: [xwiki-users] Latex html in editor for math formulas? [email protected] wrote: Hi folks, Will there be an additional button in the editor, to implement formulas? Or is there? Hi, You must be aware of this... http://i2geo.net/bin/Sandbox/Formulae There is at least a thread in xwiki-devs dealing with this issue. Look for MathTran there. http://www.nabble.com/forum/Search.jtp?forum=2564&local=y&query=MathTran Hope this helps, Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.
Alan, Ricardo, what's on i2geo.net will be published soon. It's just a macro and a javascript embedding and uses the MathTran server. The syntax? real LaTeX, which is indeed running at mathtran.org. No own macros though. That also means it's full LaTeX contrary to most latex-imitators (but which, often, can do mathml for example). We should be announcing this in a few days... probably starting as a jira issue that contains the jar. It may take a fair more time to get high-quality printouts though... i.e. either that someone works on the print-channel-through tex (which is fragile because tex is a very old system) or that we work out on the dvi inclusion in the print channel. Would there be a better space to publish these ? we could start a project on our libresource forge, but maybe the XWiki folks team has a better place? paul Le 20 févr. 08 à 10:17, <[email protected]> a écrit :
Oh thanks ricardo - that was quick
I think the MathTran should be good for now....until maybe something in-editor is developed Do you have experience with MathTran and linking it to the page? Does it work good and project all LaTex formulae?
That would be good to know, before i go out there and tell everybody i have a solution :-).
Alan
From: [email protected] [mailto:[email protected]] On Behalf Of [Ricardo Rodriguez] Your EPEC Network ICT Team Sent: Wednesday, 20 February 2008 09:57 To: XWiki Users Subject: Re: [xwiki-users] Latex html in editor for math formulas?
[email protected] wrote:
Hi folks,
Will there be an additional button in the editor, to implement formulas? Or is there?
Hi,
You must be aware of this...
http://i2geo.net/bin/Sandbox/Formulae
There is at least a thread in xwiki-devs dealing with this issue. Look for MathTran there.
http://www.nabble.com/forum/Search.jtp? forum=2564&local=y&query=MathTran
Hope this helps,
Ricardo
On Feb 20, 2008, at 10:50 AM, Paul Libbrecht wrote:
Alan, Ricardo,
what's on i2geo.net will be published soon. It's just a macro and a javascript embedding and uses the MathTran server.
The syntax? real LaTeX, which is indeed running at mathtran.org. No own macros though. That also means it's full LaTeX contrary to most latex-imitators (but which, often, can do mathml for example).
We should be announcing this in a few days... probably starting as a jira issue that contains the jar.
It may take a fair more time to get high-quality printouts though... i.e. either that someone works on the print-channel-through tex (which is fragile because tex is a very old system) or that we work out on the dvi inclusion in the print channel.
Would there be a better space to publish these ? we could start a project on our libresource forge, but maybe the XWiki folks team has a better place?
1) For publishing the jar, the best is probably the xwiki code zone 2) For the source code, it really depends on you. You have 3 options I can think of: a) a project wherever you want (sourceforge, libresource, etc) b) a project on the XWiki Forge. This is not advertised yet but we have a XWiki Forge for hosting projects related to XWiki. We give those projects a SVN repo, a wiki (as in http://<project name>.xwiki.org), a JIRA project, mailing lists, etc. Note that since the machines and admin are currently owned and done by XWiki SAS, it's its decision to decide what project get in. This project would definitely fit in. Since maybe creating a project just for one macro would be a bit too much, we could create a general purpose project for hosting outside contributions (plugins, macros, applications). Actually I think this would be a very good idea. It would be very open and anyone asking would get commit access to it. c) you're interested in participating to the xwiki development and in this case we include your macro in the xwiki source code and we vote you in as a committer to improve and support it (of course that would be after seeing the source code and ensuring it complies with the xwiki coding conventions, etc). Let us know what you'd prefer. Thanks -Vincent
Le 20 févr. 08 à 10:17, <[email protected]> a écrit :
Oh thanks ricardo - that was quick
I think the MathTran should be good for now....until maybe something in-editor is developed Do you have experience with MathTran and linking it to the page? Does it work good and project all LaTex formulae?
That would be good to know, before i go out there and tell everybody i have a solution :-).
Alan
From: [email protected] [mailto:[email protected]] On Behalf Of [Ricardo Rodriguez] Your EPEC Network ICT Team Sent: Wednesday, 20 February 2008 09:57 To: XWiki Users Subject: Re: [xwiki-users] Latex html in editor for math formulas?
[email protected] wrote:
Hi folks,
Will there be an additional button in the editor, to implement formulas? Or is there?
Hi,
You must be aware of this...
http://i2geo.net/bin/Sandbox/Formulae
There is at least a thread in xwiki-devs dealing with this issue. Look for MathTran there.
http://www.nabble.com/forum/Search.jtp?forum=2564&local=y&query=MathTran
Hope this helps,
Ricardo
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
Paul Libbrecht wrote:
Alan, Ricardo,
what's on i2geo.net will be published soon. It's just a macro and a javascript embedding and uses the MathTran server.
The syntax? real LaTeX, which is indeed running at mathtran.org. No own macros though. That also means it's full LaTeX contrary to most latex-imitators (but which, often, can do mathml for example).
We should be announcing this in a few days... probably starting as a jira issue that contains the jar.
It may take a fair more time to get high-quality printouts though... i.e. either that someone works on the print-channel-through tex (which is fragile because tex is a very old system) or that we work out on the dvi inclusion in the print channel.
Would there be a better space to publish these ? we could start a project on our libresource forge, but maybe the XWiki folks team has a better place?
paul
Hi Paul, These are great news! Even though we are still far from being able to contribute in the source side, I would like to say that being able to write "nice" formulae is a key feature for us. We have started the "TeX way" this year, so it won't be hard to integrate this new utility in our workflow. As per where to place this, is it not XWiki Subversion repository the perfect place for developing this "plugin/extension/IDontKnowExactlyWhat"? I'm sure you have already visited this place... http://fisheye2.cenqua.com/browse/xwiki/ Cheers, Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team
The more I think about the more I like idea b) below. This means there would be 2 options for anyone wanting to contribute code: 1) If the person is interested in xwiki in general, the best is the contribute it in xwiki's SVN itself and have the person be made a committer 2) if the person is interested only in a specific thing, like a macro he has developed, a plugin, an app, and is looking for a place where he/she can contribute with others on it, then this special forge project is the perfect place. Now we need to find a name for it and then creating it is quick and easy. I propose to name it "xlet" which means an xwiki extension in general. Any other idea? WDYT? Thanks -Vincent PS: for those who are maven afficionado, this is equivalent to the mojo project at codehaus. On Feb 20, 2008, at 11:08 AM, Vincent Massol wrote:
On Feb 20, 2008, at 10:50 AM, Paul Libbrecht wrote:
Alan, Ricardo,
what's on i2geo.net will be published soon. It's just a macro and a javascript embedding and uses the MathTran server.
The syntax? real LaTeX, which is indeed running at mathtran.org. No own macros though. That also means it's full LaTeX contrary to most latex-imitators (but which, often, can do mathml for example).
We should be announcing this in a few days... probably starting as a jira issue that contains the jar.
It may take a fair more time to get high-quality printouts though... i.e. either that someone works on the print-channel- through tex (which is fragile because tex is a very old system) or that we work out on the dvi inclusion in the print channel.
Would there be a better space to publish these ? we could start a project on our libresource forge, but maybe the XWiki folks team has a better place?
1) For publishing the jar, the best is probably the xwiki code zone 2) For the source code, it really depends on you. You have 3 options I can think of:
a) a project wherever you want (sourceforge, libresource, etc)
b) a project on the XWiki Forge. This is not advertised yet but we have a XWiki Forge for hosting projects related to XWiki. We give those projects a SVN repo, a wiki (as in http://<project name>.xwiki.org), a JIRA project, mailing lists, etc. Note that since the machines and admin are currently owned and done by XWiki SAS, it's its decision to decide what project get in. This project would definitely fit in.
Since maybe creating a project just for one macro would be a bit too much, we could create a general purpose project for hosting outside contributions (plugins, macros, applications). Actually I think this would be a very good idea. It would be very open and anyone asking would get commit access to it.
c) you're interested in participating to the xwiki development and in this case we include your macro in the xwiki source code and we vote you in as a committer to improve and support it (of course that would be after seeing the source code and ensuring it complies with the xwiki coding conventions, etc).
Let us know what you'd prefer.
Thanks -Vincent
Le 20 févr. 08 à 10:17, <[email protected]> a écrit :
Oh thanks ricardo - that was quick
I think the MathTran should be good for now....until maybe something in-editor is developed Do you have experience with MathTran and linking it to the page? Does it work good and project all LaTex formulae?
That would be good to know, before i go out there and tell everybody i have a solution :-).
Alan
From: [email protected] [mailto:[email protected]] On Behalf Of [Ricardo Rodriguez] Your EPEC Network ICT Team Sent: Wednesday, 20 February 2008 09:57 To: XWiki Users Subject: Re: [xwiki-users] Latex html in editor for math formulas?
[email protected] wrote:
Hi folks,
Will there be an additional button in the editor, to implement formulas? Or is there?
Hi,
You must be aware of this...
http://i2geo.net/bin/Sandbox/Formulae
There is at least a thread in xwiki-devs dealing with this issue. Look for MathTran there.
http://www.nabble.com/forum/Search.jtp?forum=2564&local=y&query=MathTran
Hope this helps,
Ricardo
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
Vincent Massol wrote:
The more I think about the more I like idea b) below. This means there would be 2 options for anyone wanting to contribute code:
1) If the person is interested in xwiki in general, the best is the contribute it in xwiki's SVN itself and have the person be made a committer 2) if the person is interested only in a specific thing, like a macro he has developed, a plugin, an app, and is looking for a place where he/she can contribute with others on it, then this special forge project is the perfect place.
Now we need to find a name for it and then creating it is quick and easy.
I propose to name it "xlet" which means an xwiki extension in general. Any other idea?
I do like both idea b) and the name "xlet". As I keep trying to enter this great developing universe, the availability of this "special forge" could ease things. Let me guess much more people are in my same situation. What I don't know is how complicated would be for "core devs" to be sure the code developed for any of the coming xlets (I've already added this new word to my dictionary :) is not dangerous for a XWiki installation. Or perhaps this must not be a concern at all for core devs and they will be used on each one's risk. Vincent, I am not so sure about this "macro" doesn't deserve its own project. Although I am just an entry level TeX user, if Paul's team is able to work out the dvi inclusion in the print channel (just copying what Paul said in his message), doesn't open the door to use TeX in many other ways? TeX tables, for instance. Thanks! -- Ricardo Rodríguez Your EPEC Network ICT Team
On Feb 20, 2008, at 12:38 PM, [Ricardo Rodriguez] Your EPEC Network ICT Team wrote:
Vincent Massol wrote:
The more I think about the more I like idea b) below. This means there would be 2 options for anyone wanting to contribute code:
1) If the person is interested in xwiki in general, the best is the contribute it in xwiki's SVN itself and have the person be made a committer 2) if the person is interested only in a specific thing, like a macro he has developed, a plugin, an app, and is looking for a place where he/she can contribute with others on it, then this special forge project is the perfect place.
Now we need to find a name for it and then creating it is quick and easy.
I propose to name it "xlet" which means an xwiki extension in general. Any other idea?
I do like both idea b) and the name "xlet". As I keep trying to enter this great developing universe, the availability of this "special forge" could ease things. Let me guess much more people are in my same situation. What I don't know is how complicated would be for "core devs" to be sure the code developed for any of the coming xlets (I've already added this new word to my dictionary :) is not dangerous for a XWiki installation. Or perhaps this must not be a concern at all for core devs and they will be used on each one's risk.
Vincent, I am not so sure about this "macro" doesn't deserve its own project. Although I am just an entry level TeX user, if Paul's team is able to work out the dvi inclusion in the print channel (just copying what Paul said in his message), doesn't open the door to use TeX in many other ways? TeX tables, for instance.
I think I was not clear. I see this macro going into this "xlet"' project but not in a project on its own since that's a lot more maintenance to do... I'd rather we have a single project for now and if one of the module in there outgrows the project then it could move to be a top level project. Hope this makes sense -Vincent
On Feb 20, 2008, at 12:42 PM, Vincent Massol wrote:
On Feb 20, 2008, at 12:38 PM, [Ricardo Rodriguez] Your EPEC Network ICT Team wrote:
Vincent Massol wrote:
The more I think about the more I like idea b) below. This means there would be 2 options for anyone wanting to contribute code:
1) If the person is interested in xwiki in general, the best is the contribute it in xwiki's SVN itself and have the person be made a committer 2) if the person is interested only in a specific thing, like a macro he has developed, a plugin, an app, and is looking for a place where he/she can contribute with others on it, then this special forge project is the perfect place.
Now we need to find a name for it and then creating it is quick and easy.
I propose to name it "xlet" which means an xwiki extension in general. Any other idea?
I do like both idea b) and the name "xlet". As I keep trying to enter this great developing universe, the availability of this "special forge" could ease things. Let me guess much more people are in my same situation. What I don't know is how complicated would be for "core devs" to be sure the code developed for any of the coming xlets (I've already added this new word to my dictionary :) is not dangerous for a XWiki installation. Or perhaps this must not be a concern at all for core devs and they will be used on each one's risk.
Vincent, I am not so sure about this "macro" doesn't deserve its own project. Although I am just an entry level TeX user, if Paul's team is able to work out the dvi inclusion in the print channel (just copying what Paul said in his message), doesn't open the door to use TeX in many other ways? TeX tables, for instance.
I think I was not clear. I see this macro going into this "xlet"' project but not in a project on its own since that's a lot more maintenance to do... I'd rather we have a single project for now and if one of the module in there outgrows the project then it could move to be a top level project.
That said I would also love if Paul wanted to join the xwiki dev team in a more general way than just this macro. In which case this macro could go directly into the platform core. But that's for Paul to decide and we would need to see the code to do some due diligence on it first. -Vincent
Vincent Massol wrote:
I think I was not clear. I see this macro going into this "xlet"' project but not in a project on its own since that's a lot more maintenance to do... I'd rather we have a single project for now and if one of the module in there outgrows the project then it could move to be a top level project.
Hope this makes sense -Vincent
Far clear! Thanks! -- Ricardo Rodríguez Your EPEC Network ICT Team
Paul Libbrecht wrote:
Alan, Ricardo,
what's on i2geo.net will be published soon. It's just a macro and a javascript embedding and uses the MathTran server.
The syntax? real LaTeX, which is indeed running at mathtran.org. No own macros though. That also means it's full LaTeX contrary to most latex-imitators (but which, often, can do mathml for example).
We should be announcing this in a few days... probably starting as a jira issue that contains the jar.
It may take a fair more time to get high-quality printouts though... i.e. either that someone works on the print-channel-through tex (which is fragile because tex is a very old system) or that we work out on the dvi inclusion in the print channel.
Hi, We're currently using FOP to generate PDFs. FOP cannot use DVIs (at least not currently, with the available external resource plugins). It does support some EPS. However, using the TeX system brings some problems: - there is a dependency on an external tool, as we cannot bundle a TeX system. - TeX is pretty slow. If it is used only for generating the PDF export of a wiki document with few equations, then that is not a major issue, since exporting PDF is not something frequently done. But imagine using it for displaying a document with several equations (>20), and how long it would take to make 20 shell commands to start TeX, generate the eps files, load those files from the disk, and send them to the client. No way this would work without a proper cache. Another way to generate nice graphics from LaTeX equations is by combining these tools: one that converts LaTeX to MathML, and one that converts MathML to something else. The first tool is needed as LaTeX is not quite an open standard. There is only one fully supported compiler, and it has limitations. On the other hand, MathML is interesting even as a final equation format, as some browsers have support for it, although with some problems. But there are many tools that work with MathML, viewers, editors, converters... Two candidates I found during a small Google session: http://math.etsu.edu/LaTeXMathML/LaTeXMathML.js -> LaTeX => MathML converter in JavaScript. The code should be converted to Java, so that the whole process can be done in the native language for XWiki. http://jeuclid.sourceforge.net/ -> MathML multipurpose tool. among others, it has a MathML => PNG converter, and a FOP plugin to directly support MathML in the XML source, which are preserved in the generated PDF. This means that we don't need to separately convert equations into something else and then include some images in the PDF, but we can use one XML file that contains all the XHTML source and the MathML equations. These tools can be combined into a Radeox filter + macro. The filter allows a fast syntax, like $$\sum(i)$$, while the macro allows some customization, like {latex:align=right|zoom=2|background=yellow}\sum(i){latex} Another TeX=>MML converter I found is BlahTeXML, but it is written in C. And the code is not so comprehensible, so porting it to java will be harder. However, by comparing the size of blah and the js converter above, I'd say that probably blah does a better job at the conversion. -- Sergiu Dumitriu http://purl.org/net/sergiu/
[email protected] wrote:
Hi folks,
Will there be an additional button in the editor, to implement formulas? Or is there?
Or how can I use formulas, maybe you know a good latex html live editor.
Since xwiki is more and more used by universities and labs….it would be nice to have something, if there already isnt?
Thanx, alan
You can also take a look at http://dev.xwiki.org/xwiki/bin/view/Design/SPAWN (volunteers needed) -- Sergiu Dumitriu http://purl.org/net/sergiu/
Vincent Massol wrote:
The more I think about the more I like idea b) below. This means there would be 2 options for anyone wanting to contribute code:
1) If the person is interested in xwiki in general, the best is the contribute it in xwiki's SVN itself and have the person be made a committer 2) if the person is interested only in a specific thing, like a macro he has developed, a plugin, an app, and is looking for a place where he/she can contribute with others on it, then this special forge project is the perfect place.
Now we need to find a name for it and then creating it is quick and easy.
I propose to name it "xlet" which means an xwiki extension in general. Any other idea?
xlet is already used for Digital TV 'lets. wiklet is already used as the name of another wiki engine. walet (wiki application-let) is free. Sounds too much like wallet. wlet is free, but doesn't sound so good. xwlet is free, but how does one pronounce it? I like xlet and wiklet... Can we use one of them although they are already used for something else? I guess xlet is not possible, as it is used by Sun in the JavaTV specification. Probably trademarked.
WDYT?
Thanks -Vincent
PS: for those who are maven afficionado, this is equivalent to the mojo project at codehaus.
On Feb 20, 2008, at 11:08 AM, Vincent Massol wrote:
On Feb 20, 2008, at 10:50 AM, Paul Libbrecht wrote:
Alan, Ricardo,
what's on i2geo.net will be published soon. It's just a macro and a javascript embedding and uses the MathTran server.
The syntax? real LaTeX, which is indeed running at mathtran.org. No own macros though. That also means it's full LaTeX contrary to most latex-imitators (but which, often, can do mathml for example).
We should be announcing this in a few days... probably starting as a jira issue that contains the jar.
It may take a fair more time to get high-quality printouts though... i.e. either that someone works on the print-channel-through tex (which is fragile because tex is a very old system) or that we work out on the dvi inclusion in the print channel.
Would there be a better space to publish these ? we could start a project on our libresource forge, but maybe the XWiki folks team has a better place?
1) For publishing the jar, the best is probably the xwiki code zone 2) For the source code, it really depends on you. You have 3 options I can think of:
a) a project wherever you want (sourceforge, libresource, etc)
b) a project on the XWiki Forge. This is not advertised yet but we have a XWiki Forge for hosting projects related to XWiki. We give those projects a SVN repo, a wiki (as in http://<project name>.xwiki.org), a JIRA project, mailing lists, etc. Note that since the machines and admin are currently owned and done by XWiki SAS, it's its decision to decide what project get in. This project would definitely fit in.
Since maybe creating a project just for one macro would be a bit too much, we could create a general purpose project for hosting outside contributions (plugins, macros, applications). Actually I think this would be a very good idea. It would be very open and anyone asking would get commit access to it.
c) you're interested in participating to the xwiki development and in this case we include your macro in the xwiki source code and we vote you in as a committer to improve and support it (of course that would be after seeing the source code and ensuring it complies with the xwiki coding conventions, etc).
Let us know what you'd prefer.
Thanks -Vincent
Le 20 févr. 08 à 10:17, <[email protected] <mailto:[email protected]>> a écrit :
Oh thanks ricardo - that was quick
I think the MathTran should be good for now....until maybe something in-editor is developed Do you have experience with MathTran and linking it to the page? Does it work good and project all LaTex formulae?
That would be good to know, before i go out there and tell everybody i have a solution :-).
Alan
------------------------------------------------------------------------ From: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of [Ricardo Rodriguez] Your EPEC Network ICT Team Sent: Wednesday, 20 February 2008 09:57 To: XWiki Users Subject: Re: [xwiki-users] Latex html in editor for math formulas?
[email protected] wrote:
Hi folks,
Will there be an additional button in the editor, to implement formulas? Or is there?
Hi,
You must be aware of this...
http://i2geo.net/bin/Sandbox/Formulae
There is at least a thread in xwiki-devs dealing with this issue. Look for MathTran there.
http://www.nabble.com/forum/Search.jtp?forum=2564&local=y&query=MathTran
Hope this helps,
Ricardo
-- Sergiu Dumitriu http://purl.org/net/sergiu/
[Ricardo Rodriguez] Your EPEC Network ICT Team wrote:
Vincent Massol wrote:
The more I think about the more I like idea b) below. This means there would be 2 options for anyone wanting to contribute code:
1) If the person is interested in xwiki in general, the best is the contribute it in xwiki's SVN itself and have the person be made a committer 2) if the person is interested only in a specific thing, like a macro he has developed, a plugin, an app, and is looking for a place where he/she can contribute with others on it, then this special forge project is the perfect place.
Now we need to find a name for it and then creating it is quick and easy.
I propose to name it "xlet" which means an xwiki extension in general. Any other idea?
I do like both idea b) and the name "xlet". As I keep trying to enter this great developing universe, the availability of this "special forge" could ease things. Let me guess much more people are in my same situation. What I don't know is how complicated would be for "core devs" to be sure the code developed for any of the coming xlets (I've already added this new word to my dictionary :) is not dangerous for a XWiki installation. Or perhaps this must not be a concern at all for core devs and they will be used on each one's risk.
Yep, core devs shouldn't bother with the code quality. If a cool macro appears there, and should be moved to the main XWiki repo, then a core dev can either ask the authors to improve it, work with the original authors, or simply take over the project, if the authors don't cooperate/can't be reached. But in an public FLOSS forge, code quality tends to improve with the project popularity. Whenever someone wants to use/improve something, it's probably that (s)he'll submit the code fixes to the forge. And when a core dev sees something nice in the forge, he can always spare some of his time and knowledge to improve it.
Vincent, I am not so sure about this "macro" doesn't deserve its own project. Although I am just an entry level TeX user, if Paul's team is able to work out the dvi inclusion in the print channel (just copying what Paul said in his message), doesn't open the door to use TeX in many other ways? TeX tables, for instance.
Thanks!
-- Sergiu Dumitriu http://purl.org/net/sergiu/
You can see first results at... http://193.136.136.185:8080/xwiki/bin/view/Sandbox/xWikiTutorial <http://193.136.136.185:8080/xwiki/bin/view/Sandbox/xWikiTutorial> it actually works pretty good. i could do everything....using MathTran....as paul suggested. ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Paul Libbrecht Sent: Wednesday, 20 February 2008 10:50 To: XWiki Users Subject: Re: [xwiki-users] Latex html in editor for math formulas? Alan, Ricardo, what's on i2geo.net will be published soon. It's just a macro and a javascript embedding and uses the MathTran server. The syntax? real LaTeX, which is indeed running at mathtran.org. No own macros though. That also means it's full LaTeX contrary to most latex-imitators (but which, often, can do mathml for example). We should be announcing this in a few days... probably starting as a jira issue that contains the jar. It may take a fair more time to get high-quality printouts though... i.e. either that someone works on the print-channel-through tex (which is fragile because tex is a very old system) or that we work out on the dvi inclusion in the print channel. Would there be a better space to publish these ? we could start a project on our libresource forge, but maybe the XWiki folks team has a better place? paul Le 20 févr. 08 à 10:17, <[email protected]> a écrit : Oh thanks ricardo - that was quick I think the MathTran should be good for now....until maybe something in-editor is developed Do you have experience with MathTran and linking it to the page? Does it work good and project all LaTex formulae? That would be good to know, before i go out there and tell everybody i have a solution :-). Alan ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of [Ricardo Rodriguez] Your EPEC Network ICT Team Sent: Wednesday, 20 February 2008 09:57 To: XWiki Users Subject: Re: [xwiki-users] Latex html in editor for math formulas? [email protected] <mailto:[email protected]> wrote: Hi folks, Will there be an additional button in the editor, to implement formulas? Or is there? Hi, You must be aware of this... http://i2geo.net/bin/Sandbox/Formulae <http://i2geo.net/bin/Sandbox/Formulae> There is at least a thread in xwiki-devs dealing with this issue. Look for MathTran there. http://www.nabble.com/forum/Search.jtp?forum=2564&local=y&query=MathTran <http://www.nabble.com/forum/Search.jtp?forum=2564&local=y&query=MathTran> Hope this helps, Ricardo This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.
On Thu, Feb 21, 2008 at 5:07 AM, Sergiu Dumitriu <[email protected]> wrote:
Paul Libbrecht wrote: ... http://math.etsu.edu/LaTeXMathML/LaTeXMathML.js -> LaTeX => MathML converter in JavaScript. The code should be converted to Java, so that the whole process can be done in the native language for XWiki. Did someone test this as a starting point? (I've never used it) http://scenari-platform.org/svn/dev-core/trunk/Jav_EXT/com/scenari/ext/latex...
-- Axel Kramer WikiBlog: http://www.groovy-news.org/e/page/axelclk
Le 21 févr. 08 à 05:07, Sergiu Dumitriu a écrit :
We're currently using FOP to generate PDFs. FOP cannot use DVIs (at least not currently, with the available external resource plugins). It does support some EPS.
Therefore I asked if drawing on some Graphics2D was doable as part of that (I suppose it could be piped along with Batik's Graphics object for example). We do have a dvi2svg tool already here. We'd still be minimal in terms of installation... the TeX fonts only and still not the TeX system.
However, using the TeX system brings some problems: - there is a dependency on an external tool, as we cannot bundle a TeX system.
No. That is the idea of using MathTran as a service... it's a remote service.... currently the macro just generates the appropriate <img> tags. All the PNG generation and TeX running is MathTran's. For MathTran to do proper alignment it should be served from the server so caching is being considered.
- TeX is pretty slow.
Damm less than FOP ! (;-)) (some FOP instances used TeX btw)
If it is used only for generating the PDF export of a wiki document with few equations, then that is not a major issue, since exporting PDF is not something frequently done. But imagine using it for displaying a document with several equations (>20), and how long it would take to make 20 shell commands to start TeX, generate the eps files, load those files from the disk, and send them to the client. No way this would work without a proper cache.
That is why MathTran is a TeX daemon... it seems to be able to make at least hundreds expressions a second. Note... the i2geo server does no rendering... it's all at mathtran's server at the open-university- of-the-uk.
Another way to generate nice graphics from LaTeX equations is by combining these tools: one that converts LaTeX to MathML, and one that converts MathML to something else.
MathML is surely very good and the MathML tool-set is far richer (see MathML software section of w3.org/Math). I can attest this many times! What's not rich enough to the taste of many mathematicians (and cannot be fully rich since this language is not specified) is LaTeX to MathML... the differences always byte TeX-experts. This is my sole reason to push a pure TeX approach such as MathTran (aside of the high-layout-quality). As I indicated at other places I wish math-input would be in three flavours: - TeX because there will always be folks asking it - some syntax (but which? Blahtex, which is known to cover the whole wikipedia? itex2mml? LaTeXMML?) which goes to MathML-presentation for supporting browsers (and pictures for others) - a content-oriented syntax that produces OpenMath or MathML-content (searchable, tooltippable, better-copy-and-pastable, ...). In all these situations the TeX fonts are very often needed to do a good quality rendering. Should I rather stop the TeX approach (MathTran has limitations e.g. with the usage of self-defined macros) and push more the MathML one? It's basically about assessing the "eternal need for real TeX". thoughts most welcome! paul
The first tool is needed as LaTeX is not quite an open standard. There is only one fully supported compiler, and it has limitations. On the other hand, MathML is interesting even as a final equation format, as some browsers have support for it, although with some problems. But there are many tools that work with MathML, viewers, editors, converters...
Two candidates I found during a small Google session:
http://math.etsu.edu/LaTeXMathML/LaTeXMathML.js -> LaTeX => MathML converter in JavaScript. The code should be converted to Java, so that the whole process can be done in the native language for XWiki.
http://jeuclid.sourceforge.net/ -> MathML multipurpose tool. among others, it has a MathML => PNG converter, and a FOP plugin to directly support MathML in the XML source, which are preserved in the generated PDF. This means that we don't need to separately convert equations into something else and then include some images in the PDF, but we can use one XML file that contains all the XHTML source and the MathML equations.
These tools can be combined into a Radeox filter + macro. The filter allows a fast syntax, like $$\sum(i)$$, while the macro allows some customization, like {latex:align=right|zoom=2|background=yellow}\sum(i){latex}
Another TeX=>MML converter I found is BlahTeXML, but it is written in C. And the code is not so comprehensible, so porting it to java will be harder. However, by comparing the size of blah and the js converter above, I'd say that probably blah does a better job at the conversion.
Hi, Paul Libbrecht wrote:
That is why MathTran is a TeX daemon... it seems to be able to make at least hundreds expressions a second. Note... the i2geo server does no rendering... it's all at mathtran's server at the open-university-of-the-uk.
By googling to try to understand what you are speaking about, I've found this (just login as guest to access the thread)... http://moodle.org/mod/forum/discuss.php?d=76857 Look at the last two entries by Cristina Berisso and Jonathan Fine (MathTran project manager). It looks like if XWiki will rely on this service something must be done to be sure it is available after August 2008. Cheers, Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team
As for their plans... http://www.mathtran.org/plans.html -- Ricardo Rodríguez Your EPEC Network ICT Team
Paul Libbrecht wrote:
Le 21 févr. 08 à 05:07, Sergiu Dumitriu a écrit :
We're currently using FOP to generate PDFs. FOP cannot use DVIs (at least not currently, with the available external resource plugins). It does support some EPS.
Therefore I asked if drawing on some Graphics2D was doable as part of that (I suppose it could be piped along with Batik's Graphics object for example). We do have a dvi2svg tool already here.
We'd still be minimal in terms of installation... the TeX fonts only and still not the TeX system.
However, using the TeX system brings some problems: - there is a dependency on an external tool, as we cannot bundle a TeX system.
No. That is the idea of using MathTran as a service... it's a remote service.... currently the macro just generates the appropriate <img> tags. All the PNG generation and TeX running is MathTran's.
That is exactly one of the problems with MathTran: It is on a remote host. This means that: - it might not be usable in some strict intranets, where there's no or restricted access to the internet - If the MathTran server is down, then no images will appear - It increases the traffic to an external server If it were to be installed on a local server, then we're back to the other problem: heavy installation.
For MathTran to do proper alignment it should be served from the server so caching is being considered.
- TeX is pretty slow.
Damm less than FOP ! (;-)) (some FOP instances used TeX btw)
Indeed, one FOP run is slower than one TeX run. But unless you write/use a TeX daemon (like the MathTran one) then you will have to run TeX many times for one document, while you would still have one FOP run.
If it is used only for generating the PDF export of a wiki document with few equations, then that is not a major issue, since exporting PDF is not something frequently done. But imagine using it for displaying a document with several equations (>20), and how long it would take to make 20 shell commands to start TeX, generate the eps files, load those files from the disk, and send them to the client. No way this would work without a proper cache.
That is why MathTran is a TeX daemon... it seems to be able to make at least hundreds expressions a second. Note... the i2geo server does no rendering... it's all at mathtran's server at the open-university-of-the-uk.
Another way to generate nice graphics from LaTeX equations is by combining these tools: one that converts LaTeX to MathML, and one that converts MathML to something else.
MathML is surely very good and the MathML tool-set is far richer (see MathML software section of w3.org/Math). I can attest this many times! What's not rich enough to the taste of many mathematicians (and cannot be fully rich since this language is not specified) is LaTeX to MathML... the differences always byte TeX-experts. This is my sole reason to push a pure TeX approach such as MathTran (aside of the high-layout-quality).
Still, it is TeX and not LaTeX, as I read in the Moodle page talking about MathTran. This is a drawback, as LaTeX users will be confused. I, for one, know only the LaTeX syntax. A problem with non-TeX is that the result is not as good looking as a TeX one. Damn, those articles look good! Still, the wiki is not meant to be the complete article authoring product. It is just the place where the authors can collaborate on the article, and have a fair preview of how the document would look, then export it as a LaTeX document which can be processed by a real tex system. And another thing is that the STIX fonts are almost (!) ready. They are passed the beta preview stage, and will soon be final. Perhaps MathML and PNG-ed MathML equation will look better with those fonts.
As I indicated at other places I wish math-input would be in three flavours:
- TeX because there will always be folks asking it
- some syntax (but which? Blahtex, which is known to cover the whole wikipedia? itex2mml? LaTeXMML?) which goes to MathML-presentation for supporting browsers (and pictures for others)
- a content-oriented syntax that produces OpenMath or MathML-content (searchable, tooltippable, better-copy-and-pastable, ...).
In all these situations the TeX fonts are very often needed to do a good quality rendering.
Should I rather stop the TeX approach (MathTran has limitations e.g. with the usage of self-defined macros) and push more the MathML one? It's basically about assessing the "eternal need for real TeX".
I'd say that the web is moving towards XML and XML languages. MathML belongs to the future. There are much more tools that support MathML than (La)TeX. Still, asking users to write MathML in the wiki content is too much. So, there should be support for LaTeX equations, but they should not be interpreted by a TeX engine (be it local or a remote service), instead they should be transformed into MathML (as good as possible, whenever there's a difference it can be addressed and fixed).
thoughts most welcome!
paul
The first tool is needed as LaTeX is not quite an open standard. There is only one fully supported compiler, and it has limitations. On the other hand, MathML is interesting even as a final equation format, as some browsers have support for it, although with some problems. But there are many tools that work with MathML, viewers, editors, converters...
Two candidates I found during a small Google session:
http://math.etsu.edu/LaTeXMathML/LaTeXMathML.js -> LaTeX => MathML converter in JavaScript. The code should be converted to Java, so that the whole process can be done in the native language for XWiki.
http://jeuclid.sourceforge.net/ -> MathML multipurpose tool. among others, it has a MathML => PNG converter, and a FOP plugin to directly support MathML in the XML source, which are preserved in the generated PDF. This means that we don't need to separately convert equations into something else and then include some images in the PDF, but we can use one XML file that contains all the XHTML source and the MathML equations.
These tools can be combined into a Radeox filter + macro. The filter allows a fast syntax, like $$\sum(i)$$, while the macro allows some customization, like {latex:align=right|zoom=2|background=yellow}\sum(i){latex}
Another TeX=>MML converter I found is BlahTeXML, but it is written in C. And the code is not so comprehensible, so porting it to java will be harder. However, by comparing the size of blah and the js converter above, I'd say that probably blah does a better job at the conversion.
-- Sergiu Dumitriu http://purl.org/net/sergiu/
Le 25 févr. 08 à 11:48, Sergiu Dumitriu a écrit :
That is exactly one of the problems with MathTran: It is on a remote host. This means that: - it might not be usable in some strict intranets, where there's no or restricted access to the internet - If the MathTran server is down, then no images will appear - It increases the traffic to an external server If it were to be installed on a local server, then we're back to the other problem: heavy installation.
This flexibility is sane I feel.
be fully rich since this language is not specified) is LaTeX to MathML... the differences always byte TeX-experts. This is my sole reason to push a pure TeX approach such as MathTran (aside of the high-layout-quality).
Still, it is TeX and not LaTeX, as I read in the Moodle page talking about MathTran. This is a drawback, as LaTeX users will be confused. I, for one, know only the LaTeX syntax.
This difference is livable to all mathematicians I know of.
A problem with non-TeX is that the result is not as good looking as a TeX one. Damn, those articles look good! Still, the wiki is not meant to be the complete article authoring product. It is just the place where the authors can collaborate on the article, and have a fair preview of how the document would look, then export it as a LaTeX document which can be processed by a real tex system.
As reaction to your concerns, Jonathan Fine has posted a blog entry: http://jonathanfine.wordpress.com/2008/02/27/using-mathtran-in- blogs-and-wikis/ which describes well the embedding methods. I tend to believe that XWiki distributions (SPAWN distributions) should ship with the medium (proxied) method (maybe optionally activated) and with DVI processing for printing (again an option, depends on the TeX fonts).
And another thing is that the STIX fonts are almost (!) ready. They are passed the beta preview stage, and will soon be final. Perhaps MathML and PNG-ed MathML equation will look better with those fonts.
There's more than the fonts... there's the layout capabilities and this is where no system competes. And, sure, Stixfonts can do a lot but they have been soooooo late that trust is not really best... the beta was for several years ago!
Should I rather stop the TeX approach (MathTran has limitations e.g. with the usage of self-defined macros) and push more the MathML one? It's basically about assessing the "eternal need for real TeX".
I'd say that the web is moving towards XML and XML languages. MathML belongs to the future. There are much more tools that support MathML than (La)TeX.
Still, asking users to write MathML in the wiki content is too much. So, there should be support for LaTeX equations, but they should not be interpreted by a TeX engine (be it local or a remote service), instead they should be transformed into MathML (as good as possible, whenever there's a difference it can be addressed and fixed).
This option has been difficult and haunting for many many many folks. Therefore I was more than happy to see the appearance of a TeX daemon in the form of MathTran. We can still shop for MathML-based solutions: - a browser-level editor (in GWT ideally(!)) - a feature-rich syntax-to-mathml-p converter - a rendering to picture and a rendering for print I'm just worried it takes muuuuch longer. paul
participants (6)
-
[Ricardo Rodriguez] Your EPEC Network ICT Team -
A.Aqrawi＠iaea.org -
Axel -
Paul Libbrecht -
Sergiu Dumitriu -
Vincent Massol