#
re: Office Open XML final draft!!! @ Wednesday, October 11, 2006 1:46 PM
The past incarnations of DrawingML have been chaotic. It would be interesting, out of curiosIty, to get an accurate history of what changed over time, perhaps to better understand what is supported in what.
Here is my take, I am pretty sure I got at least 50% of It wrong :-)
- pre-Windows 95 era, Word, Excel and Powerpoint use their own vector drawing layer used to draw shapes, pictures, diagrams, art and charts. Powerpoint, acquired by Microsoft in 1987, has by far the advanced drawing layer (bi-linear gradients, opacIty, ...), codenamed Escher (in reference of the famous mathematician).
- In Office 95, It is decided to reuse the Powerpoint vector graphics layer in Word and Excel. Migration begins.
- Migration ends wIth Office 97 where both Word, Excel and Powerpoint use the same vector graphics layer, publicly known as MSO (mso97.dll)
- In Office 2000, It's all craze about internet and Word tries to export WYSIWYG html. For that end, mark up extensions must be added to account for the MSO drawing layer. Hence the VML (Vector Markup language). Excel and Powerpoint don't support It. Internet Explorer natively supports VML (Internet Explorer's Direct animation vector drawing layer dismissed for performance reasons).
- In Office XP, VML migration ends and both Word, Excel and Powerpoint support VML whenever a document is saved as a "Single web page archive" (.mhtml extension).
- In Office 2003, nothing changes.
- In Office 12, MSO gets rewrItten wIth backwards compatibilIty in mind. The vector drawing layer uses more sophisticated drawing functionalIties which makes It easier to draw themed, 3D realistic objects. Technically, the differences are akin to the differences between GDI and GDI+. This new shared library is known as E2O and the corresponding mark up language is known as Drawing ML (Ecma TC45 specs).
- In Office 14, ??? perhaps the drawing layer is rewrItten, again, to 1) use WPF 2) to allow plugins, hence enabling much more sophisticated do-It-yourself scenarios. Use cases : custom charts ; BI analysis tools.
Stephane Rodriguez
One of the more important control points Sun insists on is that of commit rights and project managers. Only Sun employees have these rights and can hold these important positions..
The more important point is made by Marbux (below: ODF is an application specific format designed exactly for OpenOffice. While other applications might partially implement ODF, interoperability and successful ODF document exchange require the OOo code base!
From Marbux: This is the only article I've found to date where IBM (Heintzman) flat out says IBM wants changes in OOo licensing, more in line with the Eclipse and Apache licenses. See pg. 2. Significant because it feeds the meme that IBM's own ODF-based development goal is proprietary closed source built on the OOo code base, e.g., Symphony, et cet.
And that has huge signficance once you realize that ODF is not the real standard; the OOo code base is the real ODF standard. Look around the world and you see that ODF adoption decisions by governments are all in reality decisions to go with StarOffice, OOo, or OOo clones. I haven't, for example, seen a single instance where a government decided to ride with KOffice. Why would they, with the interop issues between KOffice and OOo? The fact that OOo's code base is the real ODF standard will figure strongly in the comments. Couple it with Sun's iron-fisted control of the OOo code base, and you have vendor lock-in with a Microsoft partner.
But with 70 developers committed in China, where developers salaries are inexpensive, IBM will soon be in a position to threaten to fork the OOo code base using proprietary extensions. Is that their real tactic to force changes in licensing and gov