Re: Thoughts on LibreOffice Math

> I think enabling the visual editor by default is indeed important. What is
> blocking it from going out of experimental features? I think the GSOC
> student who worked on that mentioned some crashes and I can try to debug
> and fix them. Are there other serious bugs / missing features apart
> undo/redo?

So there is a light weight todo for some of the things that would be nice
to have here:
http://cgit.freedesktop.org/libreoffice/core/tree/starmath/visual-editor-todo

Some of them, might already be fixed. Or reported as bugs, as some of the
other guys mentioned.

In my opinion the biggest problem with the current approach is that it is
unnecessarily complex, because the StarMath syntax tree is very concrete
(rather than being abstract).
So maintainability is at risk with the current approach, but a rewrite also
carries it's risks...
So it's a matter of resources and priority... Just my two cents...


--
Regards Jonas Finnemann Jensen.


On Thu, Jul 4, 2013 at 6:10 PM, Frédéric WANG <fred.wang@free.fr> wrote:

> On 04/07/2013 13:17, Michael Meeks wrote:
>
> > First - thanks so much for your contribution ! :-) it's great to have
> > someone working on and caring about math - it seems to me like you should
> > have commit access if you havn't already for that ( can you poke me with
> > your gerrit account name ;-)
> Thanks, my gerrit account is "Frédéric Wang" attached to the mail address
> I'm writing this mail. BTW, I'm not sure why, but I can not comment on
> gerrit commit. Do I need commit access for that?
>
>
>  Which of course makes life hard :-) IMHO it's fine to switch to something
> > more standard; but of course for back-compatibility we need to be able to
> > import (and probably export) (perfectly) StarMath to and from our new
> > representation.
> I think the visual rendering can be preserved when converting from
> StarMath to MathML, but the other direction is not possible since StarMath
> does not have all the MathML features. In general, perfectly preserving the
> StarMath markup is not really possible for example "a_b^c" and "a^c_b" will
> be converted to the same MathML markup and it's not possible to convert it
> back. A more serious example is "matrix{A ## B}", "stack{A # B}" and "A
> newline B" that are all exported as a MathML table with two rows A and B...
>
>
>  Having said that - I'd love to see the final small pieces (IIRC. mostly
> > undo/redo which is quite asy) for interactive editing sorted out before
> > doing a deprecate/replace. The skills gained pulling the interactive
> > formula editing out of experimental work will be useful learning for the
> > re-write :-)
> I think enabling the visual editor by default is indeed important. What is
> blocking it from going out of experimental features? I think the GSOC
> student who worked on that mentioned some crashes and I can try to debug
> and fix them. Are there other serious bugs / missing features apart
> undo/redo?
>
>          There were a number of technology suggestions in the thread too:
> > "just
> > re-use GtkMathView" - that seem to bring significant licensing and
> > dependency issues. In general, that seems deeply problematic to me.
> >
> >         Of course, if we can re-use some code from Firefox for a new
> > formula
> > editor (I assume they only render not edit) then that would be really
> > ideal - though, naturally there would need to be some degree of
> > abstracting of rendering etc. That's something I'd love to see. Editing
> > is often quite unpleasant to achieve ;-)
> >
> >         Thoughts on that much appreciated :-) how re-usable is the
> > firefox code
> > - is it a tightly coupled, vast chunk of beast tied to dozens of
> > megabytes / mega-lines of existing firefox infrastructure ? or is it
> > something smallish and re-usable ? :-)
>
> Gecko has an editor but it currently does not know anything about MathML
> and so editing it will produce invalid markup (try for example <div
> contenteditable="true"><math><**msqrt><mfrac><mi>a</mi><mi>b</**
> mi></mfrac></msqrt></math></**div> in a HTML page).
>
> Gecko/WebKit MathML code base itself is small (say about the same size as
> StarMath) but it is strongly dependent on the rest of the Web rendering
> engine (all the CSS properties, table and text layout, DOM etc) so I'm not
> sure it's a really good idea to use it in LibreOffice. The need for Web
> content is a bit different, Web people want all the CSS features like
> text-shadow on mathematical expressions or want to mix MathML with other
> languages like SVG or want to use Javascript/DOM to edit them. I think
> LibreOffice people just want basic math support without too much
> interaction with the other features of the rendering engine (although at
> least integration in the surrounding text is important). I admit that I
> didn't check GtkMathView in details, but it seemed to be a small piece of
> code that is designed to be integrated in other applications and
> interactive edition is possible. The rendering did not seem so good to me
> (a font issue on my system?) but that would be better if Khaled adds Open
> Type MATH support.
>
> --
> Frédéric Wang
> maths-informatique-jeux.com/**blog/frederic<http://maths-informatique-jeux.com/blog/frederic>
>
>
> ______________________________**_________________
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.**org <LibreOffice@lists.freedesktop.org>
> http://lists.freedesktop.org/**mailman/listinfo/libreoffice<http://lists.freedesktop.org/mailman/listinfo/libreoffice>