Re: [Libreoffice] replace Saxon/J XSLT extension functions with libxslt/c++ equivalent

Hi Noel,
Am 28.03.11 17:46, schrieb Noel Power:
> On 26/03/11 13:42, Peter Jentsch wrote:
> > Hi,
> >
> > I now have a first working implementation of the XSLT extension
> > functions which currently prevent the Office 2003 ML filters from using
> > the libxslt based transformation service.
> >
> > [...].
> wow this looks pretty impressive, but... I fear I am a little lost
> reviewing it . Any pointers to testing ? ( for the unitiated e.g. me )
There's one specific entry in the OOo bug database that talks about the
embedded OLE streams on word 2003 ml documents exported by OOo
(http://openoffice.org/bugzilla/show_bug.cgi?id=43230). It sports a zip
file with some sample documents. Beyond that, all I did was creating a
simple document with an embedded bmp file on windows, and try to export
and than reimport that using the office 2003 xml filters together with
the libxslt stuff I hacked together until I was at least able to
doubleclick and open the embedded object in the reimported file
(concluding that the ole stream hasn't been completely lost during the
roundtrip, and the filters didn't break completely by the changes
required by the switch to libxslt). As import or exporting office 2003
xml in both LibO and OOo currenlty fails with a general IO error I have
no idea what the filter originally was capable of with regard to
embedded ole objects (sorry).

Beyond that, I can only point to the Microsoft pages about Office 2003
XML, notably

http://office.microsoft.com/en-us/excel-help/features-and-limitations-of-xml-spreadsheet-format-in-excel-HA001034639.aspx?redir=0
(Features and limitations of XML Spreadsheet format in Excel), to give
you an indication on what to expect from the file format as such.
> Another thing that worries me is the windows build, I see there is a
> new PACKAGE2LIB defined but only for ( afaics ) the 'nixes, Have you
> tried to build it on windows, II think we might be able to get some of
> the windows experts to help ( iirc you will need a 'ipackage2.lib'
> file which afaik isn't always available and requires some magic
> something in a makefile somewhere 
Thanks for pointing that out. I'm only building on linux currently, so
that one went unnoticed (and I wouldn't have been able to fix it myself
either). Kendy seems to have taken on this one, fortunately.
>  
> If I understand things correctly then mostly this is already
> integrated ( and this goes a further step to remove more java-ication
> ) and being a new code/feature we certainly can tolerate the code
> needing 'more love' etc.
> On that front as a suggestion there are some helper stream classes you
> might find useful that can wrap those the hard to use uno stream
> classes, there is also  there is a memory stream class helper ( that
> might allow to avoid ( or at least hide ) creating temp files ). 
> Those SvStream type classes at least help with some of the pain of
> reading/writing basic types and strings etc. to/from stream
>
> e.g.
> http://opengrok.libreoffice.org/xref/libs-gui/unotools/inc/unotools/ucbstreamhelper.hxx#66
> ( helper for converting uno X*Stream types into SvStreams )
> http://opengrok.libreoffice.org/xref/libs-gui/tools/inc/tools/stream.hxx#782
> ( MemoryStream )
Thanks for that, I'll have a look at those.
> p.s. newfile package/inc/packagedllapi.hxx needs the standard licence foo
Yep. Also forgot the mention that any patches to existing files are
under the LGPL 3.0/MPL1.1, which they are, of course. Will add that to
packagedllapi.hxx.

> Noel
Thanks and best regards,

Peter
>