Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index

On 1/2/2011 2:29 PM, Italo Vignoli wrote:
On 1/2/11 8:15 PM, Barbara Duprey wrote:

Italo, one of the things that would make me (and maybe others here) feel
better about OOXML support is if writing to the XP formats causes LibO
to make compromises that do not have to be made going to OOXML. That is,
if documents developed under an ODF application can be converted to a
higher-quality product, in terms of compatibility of features and
formatting, when going to OOXML (even in the Transitional formats) than
they can when going to XP. Is that the case?

Writing in a different format from the native one is always a problem, and causes a number of compromises. The advantage of OOXML over the old MS proprietary formats is that is based on XML and therefore is similar to ODF in the sense that is a "container" of the document components (once you have unzipped the file, you get a number of folders and files with all the contents). The better choice is always the native format, though, and we will always promote this choice.

It would be good to know which works better for interoperability when sent to an MS-only shop -- ODF or the current OOXML. In other words, is the LibO version of OOXML a better product than the MS version of ODF? Very interesting, if so. I'd like to know which to recommend. And of course the Sun(free)/Oracle(not free) plugin for MS Office is a player in this question, too. I know it's better than the MS ODF, but how does it compare to the LibO OOXML?

Writing support of OOXML is important for interoperability, which is a key user requirement. I do not know if writing OOXML has a higher level of compromises than writing in the old MS proprietary formats, because I am not a technical expert and I trust on developers and engineers for these issues. I suppose that there are different compromises.

I guess the key issue is whether this writing should essentially be given LibO's official sanction (that is, by being included without reservation in the SaveAs dialogs, and in the Tools > Options settings for defaults), or simply available as a deprecated format when forced into it. I agree that sending back an XP format given an OOXML one is likely to cause problems for LibO (that seems to be what OOo does, opening them as Read-Only with an XP extension and a constructed name that has no relation to the original). I would definitely be against removing the capability to write those formats altogether; but the official sanction of them does not seem necessary.

I know that OOXML is a Microsoft format with many problems. I have been involved in the entire standardization process, and I was against the standardization of OOXML.

But once the standard has been approved, I have stopped fighting the document format, because I think is more important to direct my efforts towards user requirements. Please remember that TDF will strive FOR and not AGAINST, and this is a typical situation where if you are FOR user requirements you have to forget that you are AGAINST OOXML.

In my view, the user requirement is for the best possible interoperability. So I'd like to know what that is -- and there still seems to be a possibility that for new documents constructed in LibO, writing the XP formats provides better interoperability than writing the OOXML ones. That's not a FOR or AGAINST issue, it's a matter of product quality. Giving a SaveAs choice for the OOXML format, indicating that it is for recent Office versions, definitely leads people in the OOXML direction whether that has better interoperability or not. If it does, so be it -- though I'd still like to see a warning that it's not really an open standard. If people are in an environment that encourages or mandates use of open standards, this isn't one!

FOR is always stronger than AGAINST.

Unsubscribe instructions: E-mail to
*** All posts to this list are publicly archived for eternity ***


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.