Hi,
I'll have a look at libxslt and try to add support for libxslt to
XSLTFilter.cxx. I the long run I guess it'll be desirable to let XSLT
filter components tell XSLTFilter wether they want saxon9 / XSLT2.0 or
not using an additional attribute in USERDATA.
Cheers,
Peter
Am Sonntag, den 12.12.2010, 13:49 +0100 schrieb Christian Lohmaier:
Hi Giole, Peter, *,
On Sun, Dec 12, 2010 at 1:27 PM, Gioele Barabucci <gioele@svario.it> wrote:
IIRC the idea [1] was to move as much XSLT processing as possible to libxml,
not to Xalan, as libxml is already used internally by LibreOffice.
The "main goal" behind this task is to avoid the need for a
java-runtime fo tasks where it isn't needed, i.e. to replace stuff
that is currently using java with c/c++ code.
Of course it doesn't make sense to just rip it out for the sake of it,
the replacement must support the same features as the java based
implementation.
And as you already noticed it doesn't make sense to require an other
runtime environment such as mono/.net instead.
ciao
Christian
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
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.