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


Hi Peter,
 
Thanks for your answer.

in theory, com.sun.star.comp.JAXTHelper would be the correct value.
I *believe*
the <data> node should read

   <prop oor:name="Data" oor:type="xs:string">   
<value>0,com.sun.star.comp.JAXTHelper,com.sun.star.text.TextDocument,...
</value>
  </prop>
 
I tried this but it doesn't work, my package is not loaded when I put
"com.sun.star.comp.JAXTHelper" at that place which must contains in fact the
name of my filter (if I understand well). When reading code of XSLTFilter.cxx, I
saw that the name of the specific implementation is retrieved in msUserData[1]
and that stylesheet is retrieved in msUserData[5], it's why I assume that each
msUserData corresponds to the sequence of value in the data node, values
separated by semi-colon because stylesheet is the sixth entry in this string (ok
to msUserData[5] found in code).  
And also beacuse the second entry is empty and a comment in code tell that we
use this not used user data for specific implementation.
 
Thanks to have a look on this. 
 


Le 4 octobre 2011 à 04:38, libreoffice-request@lists.freedesktop.org a écrit :

Send LibreOffice mailing list submissions to
         libreoffice@lists.freedesktop.org

To subscribe or unsubscribe via the World Wide Web, visit
         http://lists.freedesktop.org/mailman/listinfo/libreoffice
or, via email, send a message with subject or body 'help' to
         libreoffice-request@lists.freedesktop.org

You can reach the person managing the list at
         libreoffice-owner@lists.freedesktop.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of LibreOffice digest..."


Today's Topics:

    1. Re: Writer : XSLT 2.0 Filters KO in LibreOffice 3.4.3        but OK
       in 3.3.4 (Peter Jentsch)
    2. tail_build again depends on l10ntools (Thorsten Behrens)
    3. Build breaks in curl (Regina Henschel)
    4. Re: Build breaks in libcmis (Olivier Hallot)


----------------------------------------------------------------------

Message: 1
Date: Mon, 3 Oct 2011 20:31:20 +0000 (UTC)
From: Peter Jentsch <pjotr@guineapics.de>
Subject: Re: [Libreoffice] Writer : XSLT 2.0 Filters KO in LibreOffice
         3.4.3        but OK in 3.3.4
To: libreoffice@lists.freedesktop.org
Message-ID: <loom.20111003T213947-83@post.gmane.org>
Content-Type: text/plain; charset=utf-8

Hi Arnaud,

arnaud.malguy@... <arnaud.malguy@...> writes:



   
    ??Hi all,
   
    ?
   
    I wrote XSLT 2.0 filters that works fine in LibreOffice 3.3.4 but doesn't
work in 3.4.3 version.
   
   It's because between these two verions, a libxslt implementation of
XSLTFilter has been added and set to default instead of java-saxon
implementation. And libxslt doesn't support XSLT 2.0
   ?
   I found a way to use other implementation (old java-saon) than defaut
libxslt in the following changelog :
   
    ?2011-02-04? Peter Jentsch?
<pjotr@guineapics.de>?
[cd9e87a248022a6a5b2f8fcd6dc5fca7432b7b38]
    ? Update of the libxslt based xsltfilter implementation.
    ? * Uses the sax document handler adapter
    ? * Uses libxslt by default
    ? * Tries to evaluate the 2nd userdata parameter of the filter
  configuration as
    ??? the name of the transformation service to use.? This should allow
extension
    ? ? authors to provide their own transformer implementation (which then
could use
    ? ? the old java based transformation service which in turn uses saxon
and
could
    ? ? provide xslt 2.0 for the TEI people for example).
    ?

...   
   
   Thanks

in theory, com.sun.star.comp.JAXTHelper would be the correct value.
I *believe*
the <data> node should read

   <prop oor:name="Data" oor:type="xs:string">   
<value>0,com.sun.star.comp.JAXTHelper,com.sun.star.text.TextDocument,...
</value>
  </prop>

but I'm not sure now. I must admit that I only tried the fallback with the
filter which are packeged and not with a user defined XSLT filter when I
wrote the code. I will test this in the course of this week and give you
feedback ASAP.



Sorry for the trouble and cheers,

Peter






------------------------------

Message: 2
Date: Mon, 3 Oct 2011 23:21:16 +0200
From: Thorsten Behrens <thb@documentfoundation.org>
Subject: [Libreoffice] tail_build again depends on l10ntools
To: Tor Lillqvist <tml@iki.fi>
Cc: LibreOffice <libreoffice@lists.freedesktop.org>
Message-ID: <20111003212116.GI5916@thinkpad.thebehrens.net>
Content-Type: text/plain; charset="us-ascii"

Hi Tor,

as a heads-up - had to revert your
a649aac68c47e40ff518d874b3c10010fb7d18fc to have Android building
again - I recall you suggested to disable building of the l10n
binaries inside l10ntools directly?

Cheers,

-- Thorsten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/libreoffice/attachments/20111003/a9e7f09e/attachment-0001.pgp>

------------------------------

Message: 3
Date: Tue, 04 Oct 2011 00:08:06 +0200
From: Regina Henschel <rb.henschel@t-online.de>
Subject: [Libreoffice] Build breaks in curl
To: LO-dev <libreoffice@lists.freedesktop.org>
Message-ID: <4E8A3246.1060508@t-online.de>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Hi all,

and build breaks again :(
This time in curl, see attached error log.

Kind regards
Regina
-------------- next part --------------
A non-text attachment was scrubbed...
Name: buildD_error.log
Type: text/x-log
Size: 13992 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/libreoffice/attachments/20111004/772ec660/attachment-0001.bin>

------------------------------

Message: 4
Date: Mon, 3 Oct 2011 23:38:33 -0300
From: Olivier Hallot <olivier.hallot@documentfoundation.org>
Subject: Re: [Libreoffice] Build breaks in libcmis
To: LO-dev <libreoffice@lists.freedesktop.org>
Message-ID:
         <CAF-YCqN5X0SKU8KaDcvaCVWdut4PprwO6enBgxanqByc4H4VrA@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

I just pulled the master (git pull -r), and libcmis is still breaking my
build on linux.

--disable cmis

configure: WARNING: unrecognized options: --disable-cmis

Thanks
Olivier


2011/10/3 Cedric Bosdonnat <cedric.bosdonnat.ooo@free.fr>

On Sun, 2011-10-02 at 23:23 +0200, Regina Henschel wrote:
I've cloned and build from master today and it breaks in libcmis. Error
messages in build_error.log cited below.

There are still some build problems on windows with libcmis as it's the
first 3rd party library to be gbuildified. Please add --disable-cmis to
the configure options to skip it while we still have the problems.

Regards,

--
C?dric Bosdonnat
LibreOffice hacker
http://documentfoundation.org
OOo Eclipse Integration developer
http://cedric.bosdonnat.free.fr

_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice




--
Olivier Hallot
Founder and Steering Commitee Member
The Document Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/libreoffice/attachments/20111003/1ac3c74f/attachment.htm>

------------------------------

_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


End of LibreOffice Digest, Vol 14, Issue 11
*******************************************

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.