+1 -- gw
2014-08-03 1:47 GMT+02:00 Andrew Douglas Pitonyak <and...@pitonyak.org>: > > 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 <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) >>> >>> >>> >> > -- > Andrew Pitonyak > My Macro Document: http://www.pitonyak.org/AndrewMacro.odt > Info: http://www.pitonyak.org/oo.php > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
