[Libreoffice] Excel 2003 XML format

[Kohei Yoshida]

Hi Peter, Thanks for your detailed status update.

On Wed, Mar 23, 2011 at 3:04 PM, Peter Jentsch <pjotr at 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