[Libreoffice] [PATCH] De-Java-ise flat XML export
kendy at suse.cz
Tue Jan 4 02:13:27 PST 2011
On 2011-01-03 at 21:06 +0100, Peter Jentsch wrote:
> I'm attaching a patch I somehow managed to patiently pull out of git :-)
> As I'm new to C++, libxslt, git and a few other things involved in
> creating the patch I feel it must be full of warts and cause random
> crashes, but it seems to work and might be useful anyway.
Thanks a lot - looks great on the first sight :-) Let me look a bit
better (unless somebody else volunteers to do a deeper review?) now.
Before pushing it to the master branch, I'd like to ask you for 2
License: Please, do you agree to license under the MPL / LGPL / GPL
combo, as recommended in
Purpose documentation: Can you please add a brief description of the new
classes in the header? Just something like:
The Reader class has to be a separate thread because of this and that.
class Reader: public osl::Thread
[So - don't describe the obvious facts, just higher level / design
> Basically, the patch provides an alternative service implementation
> to be used by XSLTFilter.cxx. Use of the libxslt implementation can be
> triggered by adding "libxslt" as second parameter to the "UserData"
> configuration of an xslt filter. This second parameter is currently
> unused for xslt filters.
> To completely remove the java dependency for xslt filters, the
> xsltvalidation service would also need to be replaced by an
> implementation based on libxslt.
> Also, the Office 2003 XML export filters use a saxon extension
> implemented in Java, which needs to be replaced by a libxslt extension
> if Office 2003 XML export should be supported without Java, too.
> The flat xml export could be implemented as a pure C++ xml Filter
> indendendently of the xslt filter, as proposed in the SDK examples, I
> suppose, and I'd like to do that next.
In fact, this perfectly fits as the documentation - so I think it would
be enough to paste most of this mail to the appropriate places.
> I personally like the idea to make the implementation to use
> configurable, instead of completely removing the Java based xslt filter
The problem then is that we would have 2 things to maintain; so I think
it is better to go with your implementation, and get rid of the Java
implementation for good. [But of course, short term we can live with
both, no problem with that.]
Thank you a lot,
More information about the LibreOffice