On Jan 8, 2013, at 4:07 PM, Rob Weir wrote: > On Tue, Jan 8, 2013 at 4:59 PM, Hagar Delest <hagar.del...@laposte.net> wrote: >> Hello all, >> >> I'm back on the dev mailing list because there are some interesting topics >> sometimes. But no further involvement in the AOO project anymore. >> >> Before AOO starts to try such OOXML filter, I think it would be interesting >> to have a global consensus about what is intended about OOXML. >> The OOXML compatibility was a rather frequent question in the Google >> Moderator session, same in the forums. >> >> If AOO offers the possibility to save in OOXML, what is the future of ODF >> then? Why users should bother with a still rather unknown format if they can >> save in OOXML for compatibility with MS Office users? >> >> So what is exactly the rationale to implement the export filter? > > There was a time, back 5 years ago, when it was not certain whether > OOXML would survive or not. I, and many others, spent a lot of energy > trying to prevent that from happening. We knew that if OOXML was > standardized and accepted that it would perpetuate Microsoft's lock-in > advantage and make extra work for competitors like OpenOffice. We > knew that if OOXML survived we'd waste resources implementing it, > rather than other, more useful features that users want. We were > right to have this concern, but we lost that battle, and these things > have now come to pass. IMHO it is time to make the best of the > situation we find ourselves in.
There is the Java based Apache POI which includes OOXML4J. I am on the POI PMC. Two of the Mentors for ODFToolkit are also on the POI PMC. I have always thought that one needs to be in the MIDDLE of this position. If the following is possible - xlsx -> ods -> xlsx -> ods OR pdf -> pptx -> odf -> pdf then the software that enables such interop will be what people in institutions will use. No institution with 2,000 desktops is going to seriously think of Apache OpenOffice as a viable solution to test unless it can do a reasonably accurate job converting. > OOXML is the default format in MS Office 2007, 2010 and 2013. Office > 2003, which defaulted to the binary formats, hits end of support next > year. So, whether we like it or not, our users will be receiving > OOXML documents from people, and when they collaborate they will want > to be able to return modified OOXML documents. > > OOXML is the new DOC format. We wouldn't think of not supporting DOC, > would we? But even as we support DOC we know that ODF, as the native > format for OpenOffice, will give the best fidelity and preservation. > Everything else other than ODF is a "foreign language" to OpenOffice > that we speak imperfectly. Differences in conversions due to the file format should be well documented. After all a choice is being made. > >> Do we really want to go this way and then handle the users ranting because >> of the glitches of such a format? >> > > This is an excellent point. We don't want users to be frustrated by a > partial implementation. So maybe it could be exposed as an > "experimental" feature? With enough samples and the knowledge of standards people like Rob we can certainly highlight the INHERENT superiority. > > >> I guess that it is still easy to get a pirated copy of MS Office nowadays. >> So if someone wants MSO for free, this should not really be a big deal (and >> MS would certainly let it be so that its OOXML still expands). And the >> numbers show that AOO has not lost its leverage compared to LibreOffice for >> example (the only other to propose the OOXML export filter). So the >> sub-question is: do really our users need that OOXML export filter? >> > > As we saw in the Google Moderator counts, this feature was near the top. > >> This is a political question. The previous OOo team took a decision. What is >> the AOO team position on that now? This could have long term consequences. >> > > I hope we can avoid the politics. For example, with the license we > have taken a pragmatic view rather than follow the copyleft purists. > Where other projects have stripped all non-GPL extensions from their > extensions repository, we're happy for our users to have a choice and > decide for themselves. > > So maybe a good compromise would: > > 1) Aim to provide the industry's best support for ODF > > 2) Continue to explain the value and advantage of ODF to our users > > 3) Support whatever formats that our users need to be productive with > OpenOffice in real-world work. Exactly. People need Interop. Without interop it will be either Microsoft Office or OpenOffice, but NOT both. > >> And by the way, what flavor of the OOXML would be supported? Transient or >> ISO? >> > > Presumably we would implement "Microsoft OpenXML", what they actually can > read. Microsoft has fixed problems when they have deviated from the ISO spec. I know of one significant instance on the initial release of Mac PowerPoint 2008. They had a patch in one month. It helped that Lawrence Livermore Labs was the one reporting the trouble. Microsoft claims to support the standard. We should support the standard, but also we should allow for deviations. Alternatively someone could develop extensions... Best Regards, Dave > > Regards, > > -Rob > >> Hagar >> >> >> Le 08/01/2013 22:17, Andrea Pescetti a écrit : >> >> >>> On 07/01/2013 Andrew Douglas Pitonyak wrote: >>>> >>>> I can read these formats in AOO, but I cannot write them. Although I >>>> remember seeing discussion on this, my current understanding is that >>>> there are no current plans to add this capability into AOO, is this >>>> correct? (or did I totally miss something and it is currently available). >>> >>> >>> I've heard for a long time (since version 3.3, and perhaps earlier) that >>> OpenOffice does contain OOXML-writing code, but that it is commented out >>> (not simply disabled at build time). Is this correct? >>> >>> If the code indeed exists and can be compiled, maybe we could start by >>> compiling it and doing some tests to see how (in)complete it is... >>> >>> Regards, >>> Andrea.
