On 02/22/2010 11:50 PM, Paul Libbrecht wrote:

Interesting,

Nothing in this documentation says in what they store the contents which is bizarre... and they seem to ignore any form of standard encoding (at least MathML, probably OpenMath since they wish computations, I guess TeX would come close to it).

They don't have any persistence implemented. The project is focused on editing the formula, so all they have at the moment is a Java object holding the formula. With that, we can serialize it any way we want.

paul

On 22-févr.-10, at 23:11, Jerome Velociter wrote:

...

http://www.ongwt.com/post/2010/02/22/GWT-equation-editor

Could be integrated as a WYSIWYG plugin to edit {{formula}} content.

-- Sergiu Dumitriu http://purl.org/net/sergiu/

...

They don't have any persistence implemented. The project is focused on editing the formula, so all they have at the moment is a Java object holding the formula. With that, we can serialize it any way we want.

I'm one of the developers of GWT Formula Editor. Serialization and de-serialization of formulas is not of a big importance for us for now. We've been focusing more on editing usability (there's still enough open questions). Never the less, support for MathML and TeX (and some other formats and computational Java libraries) is planned for the future. If you are interested in integration of GWT Formula Editor with XWiki, we can collaborate on serialization/de-serialization implementation. I suppose, that existing TeX or MathML parsers can be slightly modified to fit to our needs.

But not display it in any other format? What do you mean ?

Sounds annoying. That can be fixed. :)

Best wishes! Bulat.

Paul Libbrecht <paul@...> writes:

One first small critique I have is that you say you implement copy-and- paste but you actually only do this internally... External copy&paste needs TeX, MathML etc. serialization/de-serialization to be useful, that's why it is not implemented yet.

The claim for computability is bold, be very careful there: it would mean you can serialize to MathML content or OpenMath Computability is our main goal - we can not do without it in our main project. So we'll have it that way or another. :)

Features ordered by a priority for us: Computability. Editing usability. Good API. Platform independence and flexibility. Formula checking and analysing layers (we are going to adapt existing implementations). other features. We can shift our priorities a little if there's someone eager to participate in implementing a particular feature (e.g serialization, external copy&paste, static image rendering etc.).

but, at least now, you allow a++b which has no computability. Many editors offer both modes: with computability and without. I think, that we'll also provide both. We've divided this into several layers. The editing layer provides user with tools to specify what exactly he means when typing in a formula (the hard part).

And then come several checking layers, that will be implemented separately. There we're going to check for brackets, operators and even types (e.g grams vs newtons). Those layers are heavily dependent on the computation engine that is used in a particular project. Editing layer will show hints and marks provided by checking layers. Best wishes, Bulat.