OOMML is not supported by legacy versions of Office, so saving your document as Office 2003 format, or using the OOXML Compatibility Pack in Office 2003 won’t help you. If you do that your formulas will be converted to images and then cannot be further edited.

It isn’t clear to me why they just don’t convert the formulas back to the pre-Office 2007 MathType format when saving in to the legacy formats.

If you use Microsoft’s ODF Add-in for Word, the formulas will simply be dropped altogether.

So it comes down to this: if you use the equation editor in Office 2007 you can only collaborate with other Office 2007 users. Colleagues using older versions of Office, or Office for the Mac, or open source alternatives like OpenOffice, none of them will be able to collaborate with you.

i) The big missing feature in openoffice from the scientist’s point of view is a reference manager (the equivalent of EndNote/ReferenceManager etc). It is unthinkable these days to write a manuscript without one. For openoffice, the best I know of is BIBUS. Then of course the journals have to accept those manuscripts…

ii) I wish more journals in biological sciences would accept LaTeX.

The actual look of the equations made with the new version of office is really nice, maybe with a few updates it will be more supportable.

That breaks compatibility with previous versions of Word (<=2003) that used a version of proprietary and inferior MathType. Now that Microsoft has moved to an open standard, they should be applauded, not criticized for this change. I hope won’t be long before these publication’s review work flow catches up to this open standard.

Judging difficulty is a personal thing, but I wrote a stylesheet to get from the output that Word optimistically calls html to valid (on my one test document) XHTML+MathML in half an hour or so plus another hour or so debugging their stylesheet for them, and a similar amount of time (and less debugging) for the OO.org version.
I could do it quickly because I was using the tools I use every day and I could use those tools because the systems are generating XML. If they were writing .doc format it may not have been _much_ more difficult, but it would probably have tipped the balance to the point where I wouldn’t even have tried (actually, I probably wouldn’t have installed the office suites either).

Wouldn’t it have been better, for example, if Microsoft had worked with the MathML WG to help evolve the standard?

Ah, well, now there’s an interesting point, Microsoft are a member of the MathML3 WG and were a member of the MathML2 one as well Group members Neither Sun nor IBM have chosen to join, although IBM was a member of the earlier WGs of course. Personally I’d be really happy to see someone who works closely with an ODF implementation join the WG, but it’s up to individual W3C member organisations to decide for themselves whether to join.

And a binary format cannot be inspected or transformed? Come on, we’ve been doing this for years. XML makes some things easier, and has allowed the creation of some standards based tools, but the hard part of doing real work with Microsoft documents is just as difficult now as it was in the binary days. Remember the old saying, “You can write FORTRAN in any language”. The same thing can be said of OOXML, “You can write a opaque file format even in XML”.

XML is useful, but it isn’t magic.

In any case, I’d be interested in reading some time how well this XSLT transform handles the conversions. I haven’t seen anyone list what constructs are supported and which are not, what the limitations are and what the performance is like. A formal profile that maps between the two would be interesting.

From a practical perspective, for this to be useful, the conversion would need to be flawless, have a well-defined and useful feature set that it supports, and be sufficiently fast that it can process a document with 10’s to 100’s of equations quickly, where “quickly” is relative to user expectations for loading Office documents, which is typically less than 5 seconds.

In any case, I think I agree with your underlying premise, that given an adequate transform between the two (though I make no claim on whether the current stylesheet is adequate) and placing that transform at all places in the universe where someone is expecting MathML, then OOMML could be substituted for MathML.

And when we have access to all control points in the universe then we can at the same time also add transforms for VML to SVG, XPS to PDF, HD Photo to PNG, OOXML to ODF, .NET to Mono, etc. When this is done we can look around, admire the universe full of adapters and transformers, doing nothing but wasting CPU cycles, and congratulate ourselves on having wasted years chasing after Microsoft interfaces, while Microsoft has moved on and cemented new monopolies in other areas.

So I’ll agree with you that it can be done. I just don’t think it should be done. Wouldn’t it have been better, for example, if Microsoft had worked with the MathML WG to help evolve the standard?

You could use that same reasoning to argue that there is no difference between the proprietary Office binary formats

Not really, that’s the thing about XML, it allows the documements to be inspected/transformed, whatever. A binary blob of data is just that.

As for licences. Note I neither modify nor redistribute the stylesheet that comes with office, just run it. The version of the stylesheet on Brian Jones’ blog site (which is more or less the same) is rather strangely not covered by any licence at all as far as I can see (so the legal position of whether it is usable probably depends on which jurisdiction you are in). But in any case these (like the discussion of whether or not it’s a good thing for ISO to standardise an XML version of Word’s internal data structures) are essentially political/legal/commercial issues that are important, but essentially separate from the technical question of “can users generate re-usable standard MathML out of Word. It feels really weird to say this as a (very) long time TeX user (and maintainer of the LaTeX system) who has avoided Word (and all similar wysiwyg systems) like the plague for over 20 years but Word does have, out of the box, MathML cut and paste to the clipboard (something not in oo.org as far as I can see) and does have usable (but under documented) mechanisms for accessing the MathML from other API as well. personally I’d rather use emacs, but I’ve come to realise that not everyone feels the same way about emacs:-)

PolR,

Round tripping is important, I’m not sure how well the two MS supplied styesheets roud trip. (There are limits to how far I’m prepared in a free project to debug the code of an organisation that has I’m sure an army of QA testers to do that kind of thing). The same issue will come up with any system that isn’t actually using the MathML element structure in its editor internals. this includes OO.org which also explictly maintains the mathematics in a linear star-office (eqn-ish) format which is what’s actually used to enter/edit the mathematics. The proposition in this post is not that Word (or OO.org) should use MathML internally in its eding structures, it is that Word (like OO.org) should generate Mathml on output and store it in the zip file. My point is that technically there is no difference in information content between storing an input XML and a stylesheet and storing the result XML.

You could use that same reasoning to argue that there is no difference between the proprietary Office binary formats and the new XML standard because the binary can be transformed into the XML, and a transform is provided in the form of Office 2007.

But I think there is a big difference between a world with a single standard and a world with multiple standards and a set of transformations. This is the difference that we all see when we travel internationally with a bag of adapters and transformers. Transformation, for no purpose than to paper over vendor intransigence, introduces additional code that serves no purpose. But it will slow down processing, introduce complexity and bugs, and increase costs.

Take a look for example at Microsoft’s ODF Add-in for Word. This is their parallel argument, that they do not need to support ODF natively because they provide a translator to do this. However this translator takes 30+ seconds to translate a one-page document, making it useless in any workflow.

Note also that the OMML2MML.XSL that you are modifying is an XSLT stylesheet that ships with Office 2007 and therefore implicitly has a Microsoft copyright and license. Or do you see something that grants permission to modify and redistribute?

1- It must work both ways (ie transform to MathML and from MathML)

2- The round trip from MathML to the alternative format and back to MathML must have 100% percent fidelity.

3- The round trip from the alternative format to MathML and back to the alternative format must also have 100% fidelity.

If you don’t have both forms of 100% fidelity round trips, there would be no way to edit the text in one format and store it back in the other format while being confident the changes are properly preserved.

and the last condition:

4- Both format must evolve their new versions simultaneously in locksteps to ensure conditions 1 to 3 are preserved across the changes.

This one is the killer. Trying to have two formats permanently synchronized this way is a maintenance nightmare, especially when we discuss standards with multiple implementations maintained by different organizations.

It really is time to start using non-proprietary document exchange formats.