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.