Linked by Thom Holwerda on Mon 4th Dec 2006 22:26 UTC
Novell and Ximian The first fruit of the recently announced Novell/Microsoft interoperability agreement arrived on Dec. 4, with Novell's announcement that its version of the OpenOffice productivity suite will now support the Microsoft Office Open XML format. The release candidate of Novell's modified version of OpenOffice.org 2.02 is now available for Windows for free download by registered Novell users.
Thread beginning with comment 188123
To view parent comment, click here.
To read all comments associated with this story, please click here.
smitty
Member since:
2005-10-13

Why do you continue to ignore that I can include an AX control in ODF and achieve the same situation you continue to promote as unavoidable in OOXML. There is no difference.

You have a point, but there is a difference in how the format is used. Both formats are fine, IMO, but the way they are used is quite different. MS Office is going to use wmv, activex, and other non-portable formats inside, while OpenOffice most likely isn't. It's not really a problem with the format, IMO, just the way the different office programs use them.

Reply Parent Score: 2

hal2k1 Member since:
2005-11-11

//You have a point, but there is a difference in how the format is used. Both formats are fine, IMO, but the way they are used is quite different. MS Office is going to use wmv, activex, and other non-portable formats inside, while OpenOffice most likely isn't. It's not really a problem with the format, IMO, just the way the different office programs use them.//

Precisely! Someone gets it!

The only caveat I have is this: I would have said "OpenOffice definitely isn't". It is a prime goal of OpenOffice not to have any dependency on any one underlying platform. This is why OpenOffice can provide an executable for Windows, another for OSX and another executable for Linux, all with the exact same capabilities and all producing and reading the exact same (ODF) files.

Most decidedly, without a doubt, this is the opposite of the goal of Open XML. Open XML's goal is to be as dependant on Windows as it can get away with.

Reply Parent Score: 4

n4cer Member since:
2005-07-06

The only caveat I have is this: I would have said "OpenOffice definitely isn't". It is a prime goal of OpenOffice not to have any dependency on any one underlying platform. This is why OpenOffice can provide an executable for Windows, another for OSX and another executable for Linux, all with the exact same capabilities and all producing and reading the exact same (ODF) files.

Producing a market devoid of choice and forcing everyone to the least common denominator. No thanks.

Most decidedly, without a doubt, this is the opposite of the goal of Open XML. Open XML's goal is to be as dependant on Windows as it can get away with.

This is, without a doubt, untrue. There wouldn't have been implementations using Java, OpenOffice, Gnumeric, and other platforms/applications if this was the case, and surely the competitors sitting on the committee would've voiced concerns of such. They have not, but they have implemented OOXML tools.

Reply Parent Score: 3

n4cer Member since:
2005-07-06

You have a point, but there is a difference in how the format is used. Both formats are fine, IMO, but the way they are used is quite different. MS Office is going to use wmv, activex, and other non-portable formats inside, while OpenOffice most likely isn't. It's not really a problem with the format, IMO, just the way the different office programs use them.

This is a user issue, not a format issue. The majority of people that embed images or other data in their documents are not going to change their preferred data formats just because they're using ODF or OOXML. Both formats allow arbitrary embedded data. If a user prefers to use formats that are only well supported on one or a few specific platforms, they will continue to do so whatever the document format, and in many cases, totally oblivious of the document format. And, again, this isn't a problem in most cases because the unknown data may simply be ignored while the known data is rendered or otherwise accessed.

ODF would have to provide a standard for actively blocking/converting proprietary formats, and it just does not do this.

Reply Parent Score: 3