Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


On 25/06/2013 23:38, Khaled Hosny wrote:
Don't take my word on it. I had only a cursory look while ago, but my prejudice against any math renderer not based on TeX algorithms, and the very low typographic quality of the output gave me the impression that nothing worth saving there.
It seems to me that there are two different situations where the math rendering is wanted: as a visual preview during the current Math editing session (where a low quality could be acceptable) and for printing, PDF export etc (where the high quality is required). Perhaps the current rendering engine could still be improved in the short term. For example to use other fonts like STIX as it was mentioned in a previous thread and at least stretch the character using size variants and components to fix bugs like 32362. However if it is to be kept in the future only as a separate editor, perhaps it's not really worth it.

If I were to do it, I'd retire Math as separate application (may be keep it for old documents or people who really want to use it), and integrate math in text editing as a first class citizen, so editing a math formula is just like editing a table for example. And since MathML is the math language of ODF it should be natively supported and the rendering model be written around it.
Totally agree here. I think math should be handled as any other parts of the document and not as isolated monolithic component (I had hard time to explain that to a Mozilla developer and to some Google engineers recently ;-) ...). It's also funny to note that among the four "Most missing features" of Math according to the former developer of OOo Math, three of them were actually related to integration in a complete document...

Intends to have Open Type MATH support, currently it is just wishful thinking on my part (some people should interest in sponsoring the work, but they stopped talking to me for some reason :), and I'm not actively working on this at the moment)
Yes, that's the problem with volunteer contribution (I know that too)... As I said on IRC, the current version of GtkMathView could probably be used in the short term and that would already be an improvement over the current Math rendering anyway.

So basically, the idea would be:

1) Use a node representation (probably reusing an existing data structure in LibreOffice) of MathML as the internal format and import/export it directly as normal XML. 1a) Create a GtkMathView backend and use it to render the math in LibreOffice Writer, when printing etc 1b) Connect the existing Math import/export so that people can still use the current interface.

2) Connect an existing LaTeX to MathML converter as an input method, a bit like in Abiword (can of course be done with other input format or input modes, like AsciiMath)

3) More enhancements: make GtkMathView OpenTypeMath-aware ; direct visual edition of the math in LibreOffice Writer etc

3) is of course for the long term but 1) and 2) are really a matter of putting together existing components. So 1) and 2) are probably not conceptually hard but will require some work. Maybe that's something that can be done by a volunteer contributor that has enough time to dedicate to the project or by a student as a GSOC project or similar programs.

--
Frédéric Wang
maths-informatique-jeux.com/blog/frederic

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.