Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


Hi Peter, Thanks for your detailed status update.

On Wed, Mar 23, 2011 at 3:04 PM, Peter Jentsch <pjotr@guineapics.de> wrote:

So, I guess I'll be able to provide a patch that completely replaces
that Java bases XSLT transformations with C++/libxslt based ones in a
reasonable timeframe ... but! That work will most benefit small
documents because we don't need to start a JVM each time someone wants
to load a document. With large documents, it's the structure of the XSLT
files that affects performance most. I don't expect libxslt to do
wonders with respect to processing the quite complex rules in the office
2003 xml filters on a large document.

Understood.  Even for handling smaller documents alone, removing
dependency on JVM would greatly benefit us.  I'm very excited about
this in fact, as unnecessary dependency on JVM has been one of my pet
peeves for years.

I haven't dug very deeply into the Office 2003 import / export filters:
considering the fact that Office 2003 XML will not gain popularity in
the future, I'd be personally prefer  dropping support for it completely
and focus on creating a rock-solid OOXML/ODF roundtrip experience.

Yes, that's my view as well.

But
someone with a large body of Office 2003 XML documents will think
diffently about that. But anyway: I'm currently close to where that bug
sits, so yes, assign it to me for the moment. Unfortunately I can't
reliable predict how much time I have avaible for hacking on LibreOffice
altogether, so if I feel I'm unable to fix it I'll have to pass it on.

That's fine.  I'll assign the bug to you for the moment.  Just let us
know when you feel you are not able to handle it.

w/regard to dropping xslt filters altogeher: I see the XSLT framework as
a perfect starting point for implementing individually crafted special
purpose filters, so I really wouldn't want that to go away. Maybe it's
not the right platform for a generic bridge to that other office suite.

Ok.  So, the way I see it is that, it's probably fine to keep this
framework, but we also need to be extra careful not to over-use it &
use it only for the very simple document types.  For document types
that may allow their size to grow large (like a spreadsheet document
type, for example), we should not use this framework to develop a
filter.  We should instead consider writing a native filter in C/C++.

As for the MS Office 2003 document filters, I still prefer we remove
them and encourage people to re-write them in C/C++ (if they are still
really important) at least for the long-term.

Kohei

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.