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 <kelly...@gmail.com> wrote: > On 1 Aug 2014, at 2:42 pm, Rory O'Farrell <ofarr...@iol.ie> wrote: > >> For information: >> http://www.themukt.com/2014/07/31/never-use-microsofts-ooxml-format/ > > 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 OOXML > (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. https://www.google.com/fonts) 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 > pe...@uxproductivity.com > http://www.uxproductivity.com/ > http://www.kellypmk.net/ > > PGP key: http://www.kellypmk.net/pgp-key > (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966) > > -- Alexandro Colorado Apache OpenOffice Contributor 882C 4389 3C27 E8DF 41B9 5C4C 1DB7 9D1C 7F4C 2614 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
