On Sun, Oct 18, 2020 at 4:13 AM Dave Fisher <w...@apache.org> wrote: > Hi - > > Top posting as well. I think we should consider our goals as a project. If > one of those goals is support for ODF as a theory of everything office that > you can trust and know will remain parsable a century from now then what > does that mean for OOXML? > > Saving to OOXML is probably our most requested feature, so users definitely want it. Office suites are all about being broadly general and interoperable, there is a reason why we have the longest and most complex clipboard handling code I've ever seen, support for many raster and vector image formats, allow scripting and component development in many languages, and why we import and export documents in many formats from many vendors spanning many decades. 80% of the time users use 20% of the features, but there are many different groups of users each using a different 20% of the features. Many here sound like they don't need saving to OOXML, but the user groups that do (for whatever reason) will be negatively affected if we don't support it.
As for ODF, LO is publishing ODF 1.3, so unless we keep up, we won't be able to read all ODF soon either, let alone a century from now. > I think it means that OpenOffice could be the arbiter of converting OOXML > into ODF. As such I’m more interested of using tools like POI to drive that > conversion into ODF and leave the other direction to the commercial vendors. > > We should certainly collaborate more with POI. I have OOXML documents which open in POI but have data missing when opened in AOO. We could compare what POI does vs what AOO does to improve our OOXML filter. There are probably similar cases where AOO is better and we could improve POI from it. > There is a similar but more complex semantically conversion of PDF into > ODF. > > Alternatively, maybe there is a way to enhance plug-ability of filters > with more modern methods like OSGi. > > I haven't had good experiences with OSGi, it breaks JDBC, breaks RMI, and has problems with other cases where classes are dynamically loaded at runtime without using OSGi's own APIs to do it. AOO's UNO can only load classes at runtime and use custom classloaders. > Regards, > Dave > > Regards Damjan
