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.