Discussion:
[GSOC/LyX<-->Word]: Math export to ODT issues
stefano franchi
2014-06-08 15:25:40 UTC
Permalink
Dear all,

I would love to get some feedback on the issue of Math export to
OpenOffice's ODT, which Prannoy is currently working on.


We have a fairly comprehensive test document (lifted from the latex2rtf
project) with many different kinds of math expressions. In total, there are
73 math constructs (both inline and display). Tex4ht converts these
expressions to self-standing MathML files (later embedded in the ODT file)
and inserts the correct references in the main document.

Unfortunately, the final converted file has many errors. To be precise 14
out of the 72 expressions are not correctly visualized.

However, a careful review of the code produced by tex4ht reveals that the
MathML expressions it produces are indeed correct in all cases but one. It
is OpenOffice that fails to properly render the MathML code.
Put it otherwise: of the 14 rendering errors, 13 turn out to be OpenOffice
bugs, and 1 a tex4ht bug.

I don't think there is much we can do about the the OpenOffice bugs, beside
filing reports. Besides, a quick survey of the Libre|OpenOffice forums
shows that indeed MathML's support is far from satisfactory, but no one, as
far as I can tell, is apparently working on it. It is very low priority.

So here is the question: how do we proceed on the math conversion front?

1. Should we concentrate on creating a system to export the original LaTeX
expressions as annotation fields in the ODT file for the roundtrip
conversion?

2. Or should we perhaps explore ways to get around the existing problems,
such as, for example, converting the troublesome expressions to images
instead of MathML?

I guess the answer depends on the user scenarios. If cooperation for final
production of pdf from LyX is primary, we should go for (1). If a final
export to ODT aimed to either publishers or public at large is the goal,
perhaps we should investigate (2).

I am not a heavy math user by any means, so my imagination is kind of
lacking on this front.

Cheers,

Stefano
--
__________________________________________________
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph: +1 (979) 845-2125
Texas A&M University Fax: +1 (979) 845-6421
College Station, Texas, USA

***@tamu.edu
http://stefano.cleinias.org
Cyrille Artho
2014-06-08 23:57:02 UTC
Permalink
Post by stefano franchi
Dear all,
I would love to get some feedback on the issue of Math export to
OpenOffice's ODT, which Prannoy is currently working on.
...
Unfortunately, the final converted file has many errors. To be precise 14
out of the 72 expressions are not correctly visualized.
However, a careful review of the code produced by tex4ht reveals that the
MathML expressions it produces are indeed correct in all cases but one. It
is OpenOffice that fails to properly render the MathML code.
Put it otherwise: of the 14 rendering errors, 13 turn out to be OpenOffice
bugs, and 1 a tex4ht bug.
...
So here is the question: how do we proceed on the math conversion front?
1. Should we concentrate on creating a system to export the original LaTeX
expressions as annotation fields in the ODT file for the roundtrip conversion?
2. Or should we perhaps explore ways to get around the existing problems,
such as, for example, converting the troublesome expressions to images
instead of MathML?
Dear all,
I somehow doubt that heavy math users will even consider using *Office. And
it is possible that at some point MathML support will indeed improve.

So I would focus on the back-annotations, and see if that one bug in tex4ht
can be fixed without too much effort.

Perhaps it is possible (later) to use another tool that converts all MathML
to images, as an option? That would not require selective changes in the
conversion process (which are themselves error-prone).
--
Regards,
Cyrille Artho - http://artho.com/
Clothes make the man. Naked people have little or no influence on society.
-- Mark Twain
Alex Vergara Gil
2014-06-09 20:20:37 UTC
Permalink
sorry for top posting but
have you tryed python-mathjax??
sudo pip install mathjax

this library converts latex math to MathML representation and it is already a stable package, and since lyx already converts to latex math...

My 2c
Alex
----- Original Message -----
From: stefano franchi
To: LyX-Devel
Cc: Prannoy Pilligundla
Sent: Sunday, June 08, 2014 10:25 AM
Subject: [GSOC/LyX<-->Word]: Math export to ODT issues


Dear all,


I would love to get some feedback on the issue of Math export to OpenOffice's ODT, which Prannoy is currently working on.



We have a fairly comprehensive test document (lifted from the latex2rtf project) with many different kinds of math expressions. In total, there are 73 math constructs (both inline and display). Tex4ht converts these expressions to self-standing MathML files (later embedded in the ODT file) and inserts the correct references in the main document.


Unfortunately, the final converted file has many errors. To be precise 14 out of the 72 expressions are not correctly visualized.


However, a careful review of the code produced by tex4ht reveals that the MathML expressions it produces are indeed correct in all cases but one. It is OpenOffice that fails to properly render the MathML code.

Put it otherwise: of the 14 rendering errors, 13 turn out to be OpenOffice bugs, and 1 a tex4ht bug.


I don't think there is much we can do about the the OpenOffice bugs, beside filing reports. Besides, a quick survey of the Libre|OpenOffice forums shows that indeed MathML's support is far from satisfactory, but no one, as far as I can tell, is apparently working on it. It is very low priority.


So here is the question: how do we proceed on the math conversion front?


1. Should we concentrate on creating a system to export the original LaTeX expressions as annotation fields in the ODT file for the roundtrip conversion?


2. Or should we perhaps explore ways to get around the existing problems, such as, for example, converting the troublesome expressions to images instead of MathML?


I guess the answer depends on the user scenarios. If cooperation for final production of pdf from LyX is primary, we should go for (1). If a final export to ODT aimed to either publishers or public at large is the goal, perhaps we should investigate (2).


I am not a heavy math user by any means, so my imagination is kind of lacking on this front.


Cheers,

Stefano







--

__________________________________________________
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph: +1 (979) 845-2125
Texas A&M University Fax: +1 (979) 845-6421
College Station, Texas, USA

***@tamu.edu
http://stefano.cleinias.org

Loading...