openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guy Waterval <>
Subject Re: OOXML
Date Sun, 03 Aug 2014 03:19:04 GMT

2014-08-03 1:47 GMT+02:00 Andrew Douglas Pitonyak <>:

> I am often required to read and write DOCX files and I know others for
> which this is a need. If I cannot accurately read / write DOCX files (or if
> I suspect that it may not work correctly) then I use Word; I don't like it
> when I have to use Word.
> On 08/02/2014 10:24 AM, Alexandro Colorado wrote:
>> The Support that is done is to receieve OOXML not to produce them, the
>> discussion issue would be to support legacy formats like .doc or .xls.
>> I still dont see a point to generate OOXML and most people dont care
>> as long as they can send in office native formats.
>> I never heard someone saying, please send it on docx, your doc is a
>> closed binary format.
>> On 8/2/14, Peter Kelly <> wrote:
>>> On 1 Aug 2014, at 2:42 pm, Rory O'Farrell <> wrote:
>>>  For information:
>>> An interesting article. This brings to mind a few issues I've been
>>> thinking
>>> about for a while:
>>> - I think the rather extreme anti-OOXML stance that some take can be
>>> counterproductive. I certainly hold the view that ODF is a superior
>>> standard
>>> in many respects (though not all), however there are circumstances where
>>> it
>>> makes sense for a given piece of software to support both. For example
>>> they
>>> cite the lack of support for ODF in Google Docs and iWork; if one wants
>>> to
>>> develop software that will interoperate with these would require OOXML
>>> support.
>>> My take on the issue is that it's important to support both, because as
>>> much
>>> as we might dislike the fact, OOXML is out there and used very widely.
>>> With
>>> the work I'm currently doing on UX Write, I'm adding to the existing
>>> (specifically .docx) support with support for for ODF (.odt) and doing
>>> this
>>> in a common framework such that the app itself doesn't care which format
>>> the
>>> file is natively stored in, it will work equally well with both.
>>> Additionally, once I have the ODF support in, it will be possible to
>>> leverage this support for conversion between the two formats in both
>>> directions. I'll be giving a talk on this at ApacheCon EU later this
>>> year,
>>> and yes this framework will soon be open source - if anyone is
>>> interested in
>>> collaborating on it, please let me know.
>>> - One of the criticisms raised is that there are several different
>>> versions
>>> of OOXML, not all of which are entirely compatible. However this is also
>>> true of ODF (or at least of MS's implementation in Office 2007 and 2010;
>>> I'm
>>> not sure where the fault lies). One of the big questions I've been asking
>>> myself in the work I'm currently on ODF is whether I should have my
>>> implementation it save ODF 1.1 by default, or version 1.2 by default. If
>>> I
>>> choose the former, it will work with Office 2007 and onwards. The latter,
>>> only Office 2013 (I think). For someone such as myself writing a new
>>> implementation of the (prat of) ODF spec, and desiring compatibility with
>>> Office 2007 and 2010, which is the best choice?
>>> - I consider the use of proprietary fonts to be a separate issue from the
>>> standard itself. The specification is silent on the matter, so this is
>>> really a criticism of MS Office rather than OOXML itself. Nonetheless,
>>> it's
>>> an important one, and one I believe we should address by promoting the
>>> use
>>> of open source fonts (e.g. independently
>>> and
>>> in addition to the use of ODF. Perhaps these could be made available as
>>> an
>>> easily-distributed separate package, so that those who want to stick
>>> with MS
>>> Office for whatever reason could be encouraged to install & use them, for
>>> improved interoperability with other office suites?
>>> In an organisation where there are some users on MS and others on OO/LO,
>>> these fonts could be deployed by the IT department as part of the
>>> standard
>>> desktop image, and all templates created by the organisations could use
>>> these fonts by default, which would lead to wider usage.
>>> - Towards the end of the article, there's a discussion about the lack of
>>> support for ODF by some vendors, particularly Google and Apple. The
>>> question
>>> then is how do we fix that? My view is that there needs to be a migration
>>> path - and by that I mean not just a tool to convert documents from
>>> OOMXL to
>>> ODF, but the ability to go both ways, and work with either format for as
>>> long as necessary for the migration to complete. Most (all?) successful
>>> transitions I've seen have used a similar approach - Microsoft going from
>>> DOS to Windows, Apple going from 68k -> PPC -> Intel, and Mac OS classic
>>> ->
>>> OS X, and so forth.
>>> In the case of document formats, for a country whose government currently
>>> uses MS Office and OOXML that wants to make the switch to ODF and
>>> OpenOffice/LibreOffice/other tools, it's not going to be an overnight
>>> change. It could very well take several years, and during that period
>>> everyone in the organisation will need to have the capability to work
>>> with
>>> both formats. New or modified documents would in general be saved in ODF,
>>> but older documents as well as documents that need to be exchanged with
>>> people running MS Office 2007 or 2010 (which I think don't support ODF
>>> 1.2)
>>> would need to be in OOXML, until such time as everyone has upgraded to a
>>> fully-conformant version of MS Office, or switched to OpenOffice et al.
>>> --
>>> Dr. Peter M. Kelly
>>> Founder, UX Productivity
>>> PGP key:
>>> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
> --
> Andrew Pitonyak
> My Macro Document:
> Info:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message